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Runtime environment component services 



10 The present invention relates to runtime environment component services, in par- 
ticular to a method for presenting runtime environment component services by a 
first computer system to a second computer system over a communication net- 
work, and to a method for providing runtime environment component services, 
called by a software program being executed on a second computer system, by a 

15 first computer system over a commxmication network. 

Today, many computer networks are arranged as client-server system. That 
means, a potentially large number of smaller computer systems, like laptops or 
handhold organizers, called clients, are, temporarily or permanently connected to 
20 a larger computer system, called server. The connection between the clients and 
the server may be effected, for example, via the Internet. 

In client-server systems many software programs shall be available on the clients, 
despite of their limited storage or processing capacities. Therefore, software pro- 

25 grams can be made available to clients from a server by means of browsers, which 
transfer software programs or parts thereof from a server to a client so that they 
can be executed locally of the client. This requires that the software program or a 
part thereof be stored and processed on the client. For this purpose, the client must 
be sufficiently powerful with respect to its storage capacity and its processing 

30 capability. These requirements may conflict with the aim of having smaller and 
smaller clients, including cellular telephones, which may not have enough storage 
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capacity or processing capability for storing or processing, - respectively, large 
software programs or large parts .of software programs^. . — ; 

Frequently, a software program requested by -a. client for execution is transferred 
every time the software program shall be. executed. .The, speed of this download 
depends on the, available data transfer capacity of the network connecting the 
-server, and the client. Here, frequently the available bandwidth of the network 
connection is decisive. In many instances the described client-server systems 
would be undesirably slow in executing ^a software program, because the down- 
load takes too much time. 

Therefore, software programs ,which:are called frequently for execution on.a client 
may be pernianently, or at least for the: same time, stored on the client. This leads, 
: however, to the task of regularly, and may- be , even individually, updating a poten- 
tially large number of clients, if Relevant rsofiware.^ are amended or: up- 
dated. Considerable administration -efforts for cU systems, may be the 
consequence. \ . — : , 

■It is... also known to include into. a software program executed on a client proce- 
dxires which are executed on a server.',For example, certain more complicated cal- 
culations, the result of which may be- needed on a client, may be carried out on a 
server connected with the cUent over: a network. However, this, requires that the 
program developer includes particular ^ commands into the. code of the , software 
program to be executed on the client for calling the software program to be exe- 
cuted;on the server, in the given example .the-calculation program. This is not only 
cumbersome,vbut may also lead to inconipatibilities if the software program to be 
executed on the server is amended.;^ . . - 



Computer Software programs and parts thereof, which are called during execution 
of other computer software programs or parts thereof, are herein referred to as 
runtime environment components. The fimctionality provided by these runtime 




environment components to -calling software programs or parts thereof are herein 
referred to as runtime environment component services. In many cases, runtime 
environment components have a very large size. For example, office suites com- 
prising drawing programs and wordproeessors as well as other , tools may have 

5 sizes of 50 to 100 Megabyte which renders a distribution over the Internet diffi- 
cult. The runtime environment conipbrierits- may be implemented in any suitable 
form They may consist of compiled software program code to be executed or of 
script code in any programming larigUage-to be inteipreted before execution by a 
compiler. Runtime envirbnmeiit components are typically stored and adminis- 

10 trated on a server. . : . ' 

For the reasons mentioned above, it is a desire to make runtime environment 
component services, that means the fimctionalities provided by runtime environ- 
ment components, whifcharei for exyiple; stored on a server, available for use in 
15 software programs to be exeeutad oiij'for exaihple, clients without integrated them 
into these software programs and''%iftia%tf "*distributing them together with these 
software programs to the place of execution, for example, the clients. 

Further' tiie fixU fiinctibnality of the rahtime ehviromnent components should be 
20 available for all kinds of clients whether they are poweirfiil enough for storing or 
executing the runtime environment coihponenf or not. Further, the user of a client 
should not be charged with' the -problem whether a specific runtime environment 
corinponent is available on his client or hot. 

25 -It is, therefore, ah object of the present invention to provide a method for pre- 
senting niitime environment component services and a method for .providing run- 
time environment component services over a communication network which 
achieve these aims and avoid the drawback of the prior art. It is a fiirther object to 
provide systems for performing said methods. ' ' . ; , 
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These objects are achieved by the methods and systems according .to the inde- 
pendent claims.. Particular ..embodiments;^ thereof are defined ■ in .the^ dependent 
claims. . - . * . ... : . . r - . . : , 



5 According to the invention, a method is provided for presenting .runtime environ- 
ment component services by a first computer system to a second computer system 
- over a commimicatiqn network, said method being performed by said first com- 
puter system, and comprising the steps of: ... ; . : , 
: a): receiving a. request for a nintime environment component service via said 
10 ' - commxmication network,, said ^ request being generated by a lightweight 
t component in said second computer .system, wherein the lightweight com- 
v\ ponent corresponds to the^requested runtime .environment component 

service, . , ^ :? v ^, _ r " : ^'. . ■■.■i 

b) accessing a runtime environment component being able to provide said 
15 J : requested runtime environment rCOmpLonent, ser>?^ie^, , ^ % , - ; • . 

^ - c) executing said mntime .envirigainjjen^^^^^^ on, sdd> &st computer 

i r : system for producing a resultf acciprding tp.said;r:eceiyed request for a run- 
: r -/ ;, • time environmeiU coniponentse^Mice^. _,r'..' - '^v; / - \ ; 
h d) \ transmitting, over said network,- a;;re;JT>Qnse com^^ said result to said 
20 ■ : .0 ' : siecond computer system., v. ..or: : ' . - 

The invention comprises also a method for providing, runtime environment com- 
ponent services firom a first computer system over a communication network to a 
. second computer system, said method being executed on said ^second computer 
25 / System and Qomprising the steps of:. 

■ . a)- - -generating a., request for. a runtirtie. environment component service by 
- ni^?^? ^ ^ lightweight comppjient . of said second coiriputer system, 
, . wherein the lightweight component corresponds to the requested runtime 

^ ^ environment component service, - -^ 
30 b) -transmitting said request for said runtime environment component service 
to said first computer system over said communication network, and 
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c) receiving a response comprising a result according, to said requested run- 
time environment component service, said result being produced by a run- 
time environment component executed on said first computer system and 
transmitted with said response by said first computer system over said 
5 network. _ . . 

Thus, the runtime environment compbnent services are presented by a first com- 
puter system to a second computer system v. over a communication network, 
whereby upon receiving a request for a runtime environment component service 
10 transmitted by said second computer system over said conmaimication network, 
the first computer system executes a runtime environment component for pro- 
ducing a result according to said received^ request, and transmits - over said net- 
work - a response comprising said result to said second computer system. 

15 In the context of the present invention aaightweight component is a software pro- 
- • grain which is able to request a- runtime environment component service, wherein^ 
the lightweight component corresponds ttf this runtime environment component 
service, and wherein the lightweight component is tiny enough to be. downloaded 
' from-tlie first cofnputer system onto tlie second computer system via the network 
20 connecting the first with the second computer system within^ a time t significantly 
smaller than the time it would take to download the whole runtime environment 
cbmpbrient to which it corresponds. 

"'"Thb time t shall particularly, but ncit necessarily, be less than (8 N / Cb) + ti, 
25 wherein N is the size of the runtime environment component in bytes, Cb is the 
' average bandwidth of the network connection between the first and the second 
' coniputer system, and ti is the time needed to initialize the' runtime environment 
component providing the requested 'service in its respective local environment on 
the first computer system. In today's conunonly available network connections 
30 between servers and clients the time t will typically be about ten seconds. 
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When using networks commonly used at present for the connection of clients and 
.servers this /.time ^condition -amounts to a scope pf Ae lightweight . component 
which is - measured in necessary, storage space - less than ten or even less than 
five percent of the scope of the tota:lity of the^runtime environment components 
which can be requested by it,, including any auxiliary software programs which 
these runtime environment components need to be executed in the first computer 
-system. ; v - 

..Correspondance of the. lightweight component with the runtime environment 
component, service means, in this context,^ that the lightweight component must 
offer the second computer system access to the runtime environment component 
service made available by it. If a plurality of runtime environment component 
services is made available by the light^ej-^t cornponent,. which will fi-equently be 
the case, the lightweight .conippnent porre^onds to. this plurality of runtime envi- 
ronment component services .in the ^expjajr^^ . . , . . r r r 

; ,The inventive methods^ enable a second qpmputei^ system to use results .produced 
by, a first conaputer-.systenri. The load, of holding, maintaining and. administrating 
these runtime envirpimient components,^as well, as executing these^ runtime, envi- 
ronment components, is burdened onto said first computer system. Nevertheless, 
said second computer system can .profit firom these runtime environment compo- 
nent services^ as if the relating nmtinie environment components were .present , lo- 
cally on said second computer system. Therefore, additionahfimctionality is pro- 
vided even to those computer systems which are not powerful enough to store and 
/ or . execute the full range of runtime environment components, as for example 

• notebooks, hancUield computers, organizers and mobile telephones.. Since said furst 
computejT system and- said second computer system exchange requests for services 
and responses to said requests, rather than exchanging programming code to per- 
form the services, the amount of data transfer between both computer systems is 
considerably reduced. This shortens conamunication tinie (on-line time) and leads 

Jo faster running software programs on the second computer system. 
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The inventive methods are particularly interesting for use with a. client/server en- 
vironment: In that case, the first-computer system takes over the role of a server, 
whereas the second computer system is one of the clients. The network may be a 
local network or a wide-area network,- as for example the Intemet . 

As an example, said runtime environment component services may relate to 
graphic functions, word processing functions, document editing functions, 
mathematical functions, table calculation functions, or printing functions. Said 
runtime environment components may be, for example, of the form of application 
prograniniing interfaces or nmtime components. ^ 

The runtime environment "component ^services offered by the first computer sys- 
tem are requested, according to -the preterit invehti6n,'by means of a request gen- 
erated by a lightweight comporienftm^-the* second computer system. This light- 
weight component may issue this request in response to a call of a software pro- 
gram' being execW^ btf the secoiid*'ebrnputer systeni. However,' the lightweight 
component may also -be or have a'ftser-iriterface, so that no additional software 
programs need to be executed on the second - ■ 

The runtime environment components^ as well as possible software programs 
calling* for ttieif services may comprise coinpiled program code to be executed or 
script code to be interpreted. - ^ 

As a general advantage of the invention; all the characteristics of the runtime envi- 
ronment components residing -on saiti first computer system", for -example a pro- 
gram interface and a rxmtinie environment, can be itiade fiilly available for use by 
said second computer system. If new components or releases of components are 
added to said first computer system,' these can be rhade immediately available to 
the second computer 'system without any significant modifications or additions 
required on said second computer system; This central administration of runtime 



P 4596 DE/ARG 



. environment components reduces Jhe load of administration on said second com- 
puter system and on a client/server system in general. . . - 

' Said request,and / or said response sent over said communication net\york may be 
compliant with a predetermined communication protocol^ in. particular with the 
Internet protocol. : 

In particular, if the comniunicatipn network is an open ^yide-area network, said 
rrequest and / or said response^ may b,e tr^ oyer secure channels. For ex- 

ample, encryption / decryption technologies may be applied for. the communica- 
tion between said computer systems. , . ^ 

Said request and / or said response may. coniprise identification data of said first 
computer system, identification data of s^d second computer system, identifica- 
tion data of said runtime environment component service, and input data to said 
runtime environment; cpn^jGwn ^ ^ 

It is to be understood ^ that said, firstjco^ said runtime 

environment pomppnent services to an arbitrary number, of second computer sys- 
tems independently fi-om each;other.. Oir the other hand, a second. computer sys- 
tem may transmit its requests selectively to different first computer systems. The 
communication network may be of any type suitable for .commxmication between 
computer systems, including wired and p^ially or totally wireless..The computer 
systems may be of any type of processing environments, and. of any size.. They 
may be embedded into other systems., . . -v . ..... . 

The invention can be implemented by a computer systeni comprising, computer 
program code or application code. Computer program code or application code 
may be embodied in any form of a computer program fjroduct. A computer pro- 
gram product:, comprises a medium ..configured to store or transport computer- 
readable ^cpde,- or in which computer-readable code may be embedded. Some ex- 
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amples of computer program products are CD-ROM disks, ROM cards, magnetic 
disks or tapes, service on a network, and carrier waves. The computer program 
product may also comprise signals which do not use carrier waves, such as digital 
signals transmitted over a network. The computer program product may then be 
implemented as any transmission link, such as a connection to the Internet, or any 
LAN, WAN, telephone network, or the like. 

Further, the invention comprises runtime environment components for use with a 
method according to the invention. In particular, the invention also comprises a 
data base comprising runtime environment components relating to said services 
according to any of the inventive methods. - = ' 

The invention and particular embodiments^ thereof are exemplary described in 
connection with the drawingsf wherein - - — 

Fig. 1 gives a general overview of an implementation of the invention. 
Fig. 2 illustrates the processing of a request by a remote server framework. 
Fig. 3^ 'illustrates an implementation of a lig^ ' 

"Fig. 4 illustrates the transparent access via an object component model, ^ 
Fig. 5 illustrates an implementation of a visual Hghtweight com^ 

■ Fig. 6 illustrates remotely drawing,- ' - ■ ^ * * ' - 
Fig. 7 ' illustrates accessinjg an API, ^ ' - - " . - ^ 

*Fig! 8 illustrates the creation of a Java bean lightweight component, - . 

• Fig. 9 illustrates relating a StarOfficeBean frame window, 

Fig. 10 gives a flow chart for an example using the present invention, - 

Fig. 1 1 illustrates a client's view of a non- visual lightweight component, and 

• Fig: 12- illustrates a client's view of a visual lightweight component. 

The inventive concept may be implemented in a software system for providing the 
functionality (i.e. the services) of runtime environment components from a server 
computer system via a network to one or several client computer systems. 



^, ,: . : : : ; 



.. .;;,",i>, .a.... 
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The software system consists of tv^'O; parts, one of them being ^executed on a client, 

- the other residing and being executed on the server. The part on the:server plat- 
' form makes up the runtime environment comprising a.plurahty.of runtime envi- 

5 ronmeiit components which are able to. provide services.. Furthermore, the part on 
the server provides the necessary -communication tools -in order to comrnxxnicate 
with the client. The other part, being executed on the client, perfomis mainly the 
communication between the client, requesting a runtime environment component 

- service and the part being executed^on the server which; renders the runtime envi- 
10 ronment component service requested. The server*s part of the software system is 

by far larger in size than the client's part thereof. TWs latter part., is referred to as 
the 'lightweight component'. A typical -size of the software system's part on the 
server may be 50 to 100 Megabyte -(e.g. :oan office: software paqkage), whereas the 
lightweight component on the client.may^hayjS'a/typicalcsize of 400 Kilobyte, -and 
15 may utilize only little system resourcesr(£)EU-power5,:m^^ : - ; ; . 

The small size of the lightweight component makes it attractive to download it 
. within very short time jSrom the server to a'client when the corresponding runtime 
/.environment .component service is..actually. needed.. Then,., via .the lightweight 
20 component, the;. client has accesstdi all the seryices-presented by the nmtirne envi- 
^ronment components hosted on the seryerr : , x . ^ , . 

The lightw^eight component provides an/ application programming, interface (API) 
for any application program the, implementation of which on the client is allpwed 
25 by an implementation framework on the server. Two types of lightweight compo- 
' nents are explained in the. following; one being a standard component (referring to 
Figures 1 to 4), the other being a component rendering visual functionality (refer- 
ring in particular to Figures 5 to 9). 

30 . Reference, is' inade to Fig./l, which- illustrates the communication between the 

- server 1. and*^an arbitrary number bf clients 2, 2' which are connected via conmiu- 
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nication network 3. The server 1 presents the runtime environment component 
services to the clients 2, 2\' Server 1 hosts components 101, 102, 103, 104, 105, 
106 of the runtime environment as well as a component 100 for conmiunication 
with the clients 2,' 2' via a> network 3. The network 3 is here assumed to be the 
5 Internet, although any other network may be used as well. Each client 2, 2' is 
adapted to execute (at least) one software.program 250. 

On each of the cUents 2, 2' a Ughtweight component 210 is implemented, which 
provides services of the runtime environment components 101, 102; 103, 104, 

10 105, 106 hosted on server 1 to a software, program 250 running on the clients 2, : 
2 '! The communication with server 1 is perfonned by the communication compo- 
nent 200 via the network 3. It is to be noted; that the Ughtweight component 210 
may initially riot be ^available on theidients 2, :2\ In this case, the Hghtweight 
component 210 may^be dc)wnloadednd«i the clients 2, 2% for example, from the 

15 server 1 upon the first request for riuitime?enviroi^ component services which 
are accessible by means of the lightweight component 210. 

'•"'^ It is assuriied that on ttie clients 2,: 2' a software program 250 (e.g.: an Internet 
browser) is executed. Whenever the 'software program 250 calls for a runtime en- 

20 vironment component, for example an API 101 for providing a mathematical . 
fimction, the lightweight component 210 receives this call. The lightweight com- 
ponent 210 then transforms this call into a request and transmits it via the com- 
miinieitidn compori'ent-.200, the network 3 and the communication component 100 
to the server 1 ,*where the API component 101 called for is residing. 

25 • ' ^r.\ ^..-.'^ ...>;. ... ■ ■ ■v:;^;-. - . - . . - 

' Fig. 2 to 4 how illustrate the processing for presenting / providing the runtime 
- environment component services in -more detail. . ^ : . : 

Referring to Fig. 2, the lightweight component 210 receives a call for an API 
30 component 101 from the software program 250 running on the client 2. With the 
~ call, data (e.g. arguments) necessary for performing the requested" runtime envi- 
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ronment component service of API , component 101 is received. The lightweight 
' component 210 transfonms. the received call into a .request to be transmitted over 
.the network. 3 to the server I which/actually hosts the runtime environment, in- 
.eluding the now requested API component 1.01. . , ? ■ 
5 - ' . r - 

The transmission of the request over the network 3 is performed according to a 
predetermined transmission protocol. The transmitted request contains the data 
(e.g. arguments) from the calling software program 250 for being processed by the 
i API component 101. If the network 3: is publicly accessible, the transmission may 
10 be encrypted according to known technologies. Further, digital signatures can be 
' .used to provide certification of the request mechanism being estabhshed on the 
client for this runtime environment;component services system. 

The request is received by the\serv:eri> on which the: appropriate communication 
15 „ component 100 is executed.. The: cpmm 1.00 transforms and 

decrypts (if necessary) the transmittejjrejquest,. performs digital ^signatiu-e proc- 
essing,- and accesses the^equested API component iniplenaentingjthe, desired 
mathematical function. This API component 101 is executed on the server 1, 
^. ::wh(5rebyrthe,dat^:(e.g.: argumentsX^^^^ the. request are: pirocessed, iJhe 

20 . result thereof is encrypted (if necessary), by the comniunicatipn Qpmponent 100 
. and transmitted from-the server 1 back^to^the client 2.; . ^ . . ^ : h. 

The lightwdght component 2L0 on the client receives and re- transforms the result 
(and decrypts it, if necessary) and provides the result to the software program 250 
25 haying called for .the . service of the APTeomponent 101. - . ; 

Thus, the lightweight component, 210 on, the client 2 delegates calls to the API 
component 101, which may be part of an implementation framework on, the server 
1. The lightweight component 210 operates hidden to the calling software pro- 
30 : gram of the c^lient 2. The called runtime environment component 101 is executed 
:; on the'seryer:I.. Ho>yever, the, calling software program -250 on the client 2 does 
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not notice whether the execution of the runtime environment component 101 is 
local, i.e. on the client 2, or remote, i.e. on the server 1. The calling software pro- 
gram 250 does not need to be modified for the use with the lightweight compo- 
nent 210, since, the call for a runtime environment component is *interceptedVand 
5 transformed into a suitable request to the server 1 by the lightweight component 
210, according to the invention. . ^ = 

On the other hand, local services available on the cUent 2, including devices . like 
printers and local storagie, can also be utilized by the runtime environment com- 
10 ponents on the server 1, in a transparent manner. Transformation of the call of the 
. software program .250 to the lightweight component .2 10 and re-transformation of 
the result received from the server 1 are performed "on the fly". 

Fig. 3 illustrates^ the impletneritation of the lightweight component 210. As men- 
15 tidned above, the component 210; whi<ihi is necessary for transforming the call can 
be k^t relatively smalL It can have ra;~sniall installation size and low usage of re- . ! 
^ sources compared to the nmtime enyirbnitieht- components on the server L 

- Fig. 4 exemplary illustrates the transparent access of a runtime environment com- 
20 ' porient via an object component mbdel.^ The object component model handles • 
calls by marshaling requests for runtime environment component services through 
stub objects 200' on the client 2 and transmitting it over the network 3 to the 
server' 1 . There, the requests are unmarshaled through proxy objects 1 00'. 

25 The stub objects 200' and the proxy^objects 100' aire generated dynamically; for 
example, by the communication component 200 and by the commvmication com- 
'porient 100, respectively. Therefore,- a 'calier does hot have to implement the stub 
objects 200' and the proxy objects 100'. ' - . 

30 ' Marshalling of a request is, in the present context, uiiderstood' as- the process of 
embedding a request for a runtinie- environment compisnent service Ari a bit stream 
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for transmission over a network. The unmarshalling, is the inverse process of the 
marshalling, ^ : , _ . ; , 

. ^ The transmission concept through stub .and proxy objects, is described in more 
5. : detail in the Annex. ^ ^ , , . 

The stub / proxy object component model used here implies that a lightweight 
Qomponent is able to . access any arbitrary runtime, environment component 101, 
,102, 103, 104, 105, 106 available- qn the server 1, as if it resided locally on the 
10 , client 2. . . ^ . , . 

Referring to Figures 5 .to 7, a fiirthqr embodiment qf a lightweight component 210 
is explained. The commumcation bet\Yee^ and tlie client 2 is per- 

- -formed, via the network 3 by the resDective co^^ components 100 on ' 

15 the server 1, and 200 on the client 2. The sarne encryption / decryption mecha-, , 
nisms as indicated above may be applied. In addition to the basic generic light- | 
^ weight component 210 as, described; in^ connection with Figures .1 to 4, the light- I 
weight component 210 may include^the. ability to perform graphic interaction and 
to manage user interaction. In the following, such a component is .referred to as a 
20 visual lightweight component. Such a.graphic interaction vmay comprise drawing 
-visual contents on the client 2, for example, on a -screen of a client laptop, Again, 
. -as described above, the main pait\qf; Ae processing :is^ b^ runtime \ 

^ environment component residing and ruimng on -t^^ - . . . . . , , 

25 ^/The protocol ;Which may be used for trejismitting graphical Tequests. between the 

client 2 and the server 1 -is. the Remote Visualization Process protocol (RVP). ^ 
RVP is a high level definition of a graphic device defined as a set of interfaces. | 
RVP is based completely - on a component^ infrastructure. .This gives RVP the abil- 
ity to map functionality which a client system is unable to support, to a service ' 

30 . -.component iD^^^ „ . , ; : i 
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The graphical environment may communicate with the lightweight component 
210 through the Java Abstract Window Toolkit layer (AWT). AWT stands for the 
definition of the graphic and user interface layer for the Java language. It is de- 
fined as a set of Java^ classes and ^interfaces' which are mapped to the concrete im- 
5 plementation on different platforms. AWT is part of the standard Java environ- 
. ment. 

The service component on the server side uses a VCL implementation as drawing 
engine. VCL (Visual Class Library) is a C^~^■ class library . It provides similar to 

10 the AWT a set of classes and interfaces to build graphical applications on differ- 
ent platforms. For every platform there is a concrete implementation of VCL. For 
the lightweight^ visual ^components,-* VCL provides a special implementation, 
which transmits all graphical requests for drawing over the network to a client 
side, where these requests 'are iriterccpte^^ and mapped to a platform dependent 

15 graphic layer, which is here AWT. ^'^'^ ^ • - - 

- Again, the implementation frainewbrk on- the server handles^ drawing and user 
interaction transparently to tlie Gornponeri^ - - * ^. ^ c . w :v 

20^ Fig; 5 illustrates RVP event'processiiig.^ The visual lightweight component 210 is* 
• embedded in a graphical environmtot, the- graphical environs comprising a 
^ ' display software progriam 250 with. a-graphical user interface (GUI). The graphical 
user interface is referred to as a paneK An example of an implementation is a Java 
bean which is embedded in an HTML page and rendered by a browser. This Java 
25 bean represents a view (in a window) of an office application component -(e.g. 
StarOffice Writer) or another visual office component. 

- An event firom the graphical environment is passed to the AWT 260, and' then 
- interpreted by the RVP protocol layer, which performs communication between 
30 the client visual lightweight component -210 and the remote office runtime envi- 
ronment component implementation 110 on the server platform 1. From RVP 220 
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-: the event is marshaled by communication component 200 and transmitted to the 
. server 1 . There, at'is unmarshaled and :passed to tlie RVP 120 by commimication 
component 100, and dispatched~by the VCL layer. 140. ... 

5 The runtime environment component 110 receives the event. After the event is 
dispatched, the component 1 10 is able to react to the event; 

Fig. 6 illustrates the transmission: of , the response of the component 110 on the 
server 1 back to the requesting client 2^ The requested service is here a drawing 
10 ftmctionality which is implemented by RVP drawing. The office component (e.g. 
: the StarOffice Writer) J 10 is able to. draw on a panel within software program. 250 
of the clienti2 using the same mechanism as described above. The component 110 
- uses the VCL 140 as a drawing. engine;: The operations are. transmitted through 
VCL 140, RVP 120 and communication^: component 100 on the server 1 to the 
15 client 2, Client 2 receives the operations and passes them to the AWT 260 which 
is able to draw on the panel'of the elient;Z directly.^ \ - : : 

Fig, 7 illustrates, accessing an API as a-runtime envirormient component, on .the 
, server 4 by the cUent 2. The visual light\yeiglit component 210 is,.iii the example 
20 - described iii Fig. 5 and Fig. 6, still able to.access transparently the full fimctiorial- 
ity.of.an API 104 provided by the office component 1 lO. The request of theJight- 
weight component 210 for API 104 is handed over to the office component 110 
: through the commiinicatiori component. 200 on the client 2 .and the commimica- 
:tion component 100 of the server 1. Herein, ;the request for the API 104: generated 
25 . by the hghtweight component 2 10. may. bypass RVP 220 and. AWT. 260 on the 
client 2 and likewise RVP .120 and VCL 140 on the server 1, if not drawing serv- 
ices are: requested. The latter (would be the .case, for example, iL APL 104 would 
provide calculation services.^ In order to^have the request bypass the mentioned 
- components the. Hghtweight component 210 must decide that these components 
30 shall be bypassed; This decision can-be made by the lightweight component 210 
based on the call.of the API 104. received from the software program 250 and the 
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information that the API 104 does not provide drawing services. This information 
will regularly be present in^the lightweight component 210, since it has informa- 
tion about all runtime environment components being available on the server 1 
anyway, since it has to request their services and receive their responses. How- 
ever, if necessary the office component 110 may also react to the request for API 
104 by drawing via RVP 220 directly on the panel of client 2. 

An exemplary scenario for the latter might be-^ the following: a user on client 2 
editing a text document displayed in his browser whishes to change the font size 
to 10 points throughout the whole document. For this purpose, the client 2 uses 
the API 104 to change all fonts throughout, the whole document to a size of 10 
points. In this case, the officecomponent^l 10 running on the server 1 re-calculates 
the display of the, document, renders the^ document remotely, and draws the docu- 
. ment on the client 2 throughvthe RVP^ 120 and RVP 220. ^ 

However, if the user on client . 2 changesi the fotit size^only for newly input text 
lines, the currently displayed document does not change, thus there is no need to 
re-draw the >vhole document on the clieitfct 2: The event of changing the font size is 
passed via RVP 120 to the office: cornponerit 104 and forces new rendering of the 
document on the server 1.: Since noire-rdrawing. of the document on the client 2 is 
needed, the lightweight component^lO does not have to take any further action. 

The, participating components to create a Java bean lightweight component in the 
frame of the office appUcation pro grata package StarOffice used as a runtime en- 
vironment component are shown in Fig. An accompanying sequence diagram is 
supplied in Fig. 9, The figures are reduced to show only needed relations and 
methods to illustrate this specific process. A StarOfficeBean represents a* common 
Java bean which is derived from a java^panel. It resides on the client as the single 
instance Connector, .which is responsible for maintaining connections to the re- 
mote machine. All client beans share one- connection per user and server. The 
OClientFactory created by th& Connector is also located at "the .client 2. This en- 
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ables the^ remote Office Component to, create i elements which are specific to the 
. client 2. Examples for these items range from a simple frame window to a . printer 
device handled locally. Next the Co/2wec/or establishes a connection to the remote 
machine and starts the login process. If succeeded the server 1 starts a StarOffice 
5 session remotely and the Connector confirms the session with StartQ. The task of 
the remote MM/^ZiS^rv/ceFac/oo^ created by is to cre- 

ate needed instances on the remote machine. Then a local ORmFrameWindow is 
created and passed together with a reference of ihc OClientFactory to the remote 
StarOffice instance to be able for local- dispatching and drawirig. By calling ini- 
10 tializeQ on the remotely created JavaBeanFrame all actions are done and the pro- . 
cess of creating a StarOfficeBean is completed. 

Unlike components like CpRBA;,obje^^^^ components .210 do not 

. .have any additional code for accessing. Jtoe-implementi^ Also, the size of a 

15 lightweight component 210. does nQt^ increase with^^the number of access^^^ run- - 
time environment components of the^iiti^slementation seryer^framework^Th^ in- 
troduces the ability to offer components which expose only services designed for 
. , aspecial puopose and hide complexitv^ 

20 By^ applying .the invention, it is possible to include for example full word proc- e 
essing .fimctionality provided by^the se:;yer 1 into any. other application program 
250 running on the client computer,2.- . - . - . , , . 

Special purposes may be applications; designed for being .executed. on particular 
25 clients like handheld cornputers or mobile .telephones,, where stpr^age and proc- 
essing capabilities are particularly limited. Nevertheless, the whole fimctionality 
, of the framework is still accessible. . . ^ , . : _ - ^ - , . . : , 

Furthermore,, when adding new runtime. environment cpniponents to the server 1, 
30 . no modification on the .client side is, necessary. Through. the concept of light- 
weight components, a new runtime environment component on the server is im- 
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mediately callable by the client. The components are based oh a generic light- 
weight component which is- able to communicate with the implementation frame- 
work via the object compbherif model; * ' 

5 Fig. 10 refers to an example for using the present invention. In this example a 
setup is used as described iri^Fig. 5 to -7. Therefore, reference nurherals also relate 
to components which -are- presented and described' in more detail in connection 
with Fig. 5 to 7. However, the method according to Fig. 10 does not correspond to 
the methods described along Fig - 5 to -7: *- ^ v . 

In this example, a user utilizes his computer system as' a client 2. This client 2 
includes a screen on which the user can edit and process a text document. The 
client 2 includes text-processing softwaire'isO with a limited scope of functionality 
and a lightweight component 210 wMcHt corresponds to comprehensive services 
15 ' dffered'by ah office suite soflSvat¥ pae^ 110 located as runtime environment 
cbriipohehts on a server 1 to which thSsclient i is connected via a network 3 . r 

For the purposes of this' example the useV edits a text document on the screen of 
the client 2 and changes the font size of the text. In order to do this he inputs his 
20 • commands via^aisuitable input device'of the client 2j for example, a keyboard. In 
' step 1010 the text processing software 250 on the client 2 requests the service 
"font change" from the lightweight component -210: The lightweight component 
210 receives this request in step 1020. In step 1030 the Ughtweight component 
' - 210^mar3hals the re^quest and transmits' it via the' communication component 200 
25 ihxlient 2 to the coininxinication component 100 of the server 1 via the network 3. 

The server 1 unmarshals the request and calls the runtime environment component 
110 in step 1040. In the next step 1050 the component 110 starts processing the 
' "font change" request. It will determine in step 1060 if a re-drawing of the text 
30 document on the screen of the clierit 2'is necessary due to the requested font 
change. - • ' : - . ' . . ^ ^ ^ . . . , 
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If not, the service component 110 will immediately.produce a result to the request 
in step 1080. A re-drawing may not be necessary, if the user, wants the font 
change to be effective exclusively for further input into the text document. In this 
5 ' case the result to be provided .by component 110 could be a retum code to the 
software program 250 which tells the softv/are program 250 that further input into 
the text document will be processed with the new- font on the screen of the cHent 
2. 

10 If yes, for example, if the font shall be:changed for the whole text docxmieht, the 
component 110 renders a new graphical presentation of the. text document in step 
1061. Then, in step 1062, the . output operations for the realization of the graphical 
presentation are given to the VCL I40:by the component 1 10. In step 1.063 it will 
be decided by VCL 140 whether the^ output operations have tO; be carried out in a 

15 ^visible area, e.g. on a screen.^, ^.rr. ,0* : vc:. • ^ . </ v: ^ - 

If this is not the case, for example, if the text document with the font changed 
i throughout dts: .entire scope/would only: be> stored as a data file but not shown on 
r the screen , of %the client 2, .the result -would be created in - step .:1 090. by VCL 140.' 
20 .This result would be the .text document in:the new form.; No display on the screen 
.of the client 2 would be, envisaged in this case. . : . : r 

..If this is the. case, for example, if the text,, document shallobe. displayed, onv the 
screen of the client 2, the "change, font"; request realized by. VGL 140 is transmit- 
25 • ted to RyPr 120 in step>1064. This realizedjrequest is then, in step^ l065,: marshaled ^ 
and sent via conimunication component 1 00. of server, 1, via the network 3 and, via 
. the communication component 200 .of the client 2 to the lightweight: component 
210 on the„client2. In step 1066 the lightweight component 210 vmmarshals the 
realized request. In step 1067 the request is translated into an AWT request. This 
30 AWT request is transmitted in step 1068 from the lightweight component 210 via 
the RVP 220 to the AWT 260. In step 1069 the AWT 260 executes the transmitted 
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AWT request. Finally, in step 1070 the result will be transmitted to the software 
program 250 so that the text document will be drawn on the screen of the client; 2 
with the new font size. \ . : a , . , ' 

Fig. IV illustrates a non-visual lightweight component. Non- visual means that the 
user ofithe client on which the lightweight component is located does not receive 
any hints as to its presence. He does not see it and he can also not interact with it 
directly. 

In Fig. 11a client 1110 is shown with a^-screen. showing, - on the left,^a tree-like 
representation of data files below a window; and, on the right, information, given 
about a certain text document which- was selected by the user by means of the 
itree-like representation of data files. /PheOclient. 11 10 is connected .via: network 
, 1120 to a server 1130 wWch hasiaccess!to:.a tex processing software program as 
runtime environment component 1 140. This component 1 140 has in turn access to 
a storage medium 1 150 and to a library 1 160. 

If a user of the client 1110 wants to obtain information; for example, nurnber of 
words .and lines, author arid date of this version, about aitext document chosen 

.:from the tree-like representation of data files, he enters his request via an input 
device of the client IHO, for example, ca keyboard of the client 1110. Then, the 
non- visual lightweight component on the client 1110 will contact, as described 
above,; via the network 1 1 20 the server^l 130 and ask for the services providing the 
information requested. by the user from the runtime environment component 1 140. 

• The result provided by the, component 11 140 will then be re-transmitted to the; cli- 

.ent 1110 so that the desired information - number of words and lines; author and 
date of this version of the selected text document - can be displayed on the screen 

' of the client 1110. The lightweight component remains non-visual to the user of 
the client 1110; ^ ^ : : • . 




Fig. 12 in contrast shows an example of a visual lightweight component, that 
nieans a lightweight component with which the user may interact, but which will 
at least be recognized by the user in some situations, 

5 A client 1210 includes a visual lightweight component. The client 1210 is con- 
nected via network 1220 with the server 1230, which in tum has access to the 
runtime environment component 1240 connected to storage mediimi 1250 and 
data base 1260. 

10 In this example, a user of the client 1210 edits a text document on the screen of 
the client 1210, as shovra in Fig. 12 on the right, besides the above described win- 
dow and tree-like representation of data files. The shown screen representation of 
the text document shows in the right middle position a small window with which 
the user may manipulate the displayed text document. This window represents the 

15 lightweight component. Here, the user may directly interact, via the window pres- 
entation, with the lightweight component, which is therefore referred to as a visual 
lightweight component. 

If the lightweight component is activated by a user interaction it may contact, as 
20 described above, the server 1230 and thereby the runtime environment 1240, 
which may provide a service requested by the user by his interaction firom the 
client 1210, 

Comparing a non-visual and a visual lightweight component as above described, it 
25 may be advantageous to use a non-visual lightweight component for processing 
requests which do not require particular operations for their fulfillment, in par- 
ticular, no drawing operations on a screen of a client. In this case, the non-visual 
lightweight component may provide the response to the request more quickly than 
a visual lightweight component, since, for example, drawing operations are not 
30 processed at all; they are not only ignored by the client after having been proc- 
essed with great efforts. 
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It is understood that the present invention is not limited to the embodiments 
shown and described herein. 
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- -The present invention relates to a method for enabUng a first software program 
5 ' ' using a first ^binary specification to employ a„ limited fimctionality of a second 
software program using a; second binary: specification. 



Many software programs, which are -created in different programming languages, 
have to communicate with each other; for exaniple, a first software program cre- 
10 ated in a first programming language is able to provide tables. It calls another 
software program created ..in , a :second, programming language which is able to 
calculate figures which are needed/ in the table to be produced by the first pro- 
' ' gram. The calculation program cannotbe called by the table program,, since these 
two programs use different binary specifications for the communication: becaiise 
15 of their different programming languages. In the context of the present invention 
the different binary specification-rqan^be v caused; by differen^^ programming lan- 
^ guages as well as by different .CQfripil^fs for the, same prograinming lang^ 
. : since -the communication problems; (paused by a, different prpgraimning language 
and by different compilers for the same programrping language are coniparable, if 
20 '--riot identical. . : v; ^ .\,"r . ;i / r f ' • 

The prior art solution to. this problem is. to. provide transformer modules for each 
required transformation route, for.example from a certain first binary specification 
to a certain second binary specification. Since in ,mpdeni:Computer applications 

25 - many different software programs may. be called by; a certain software, prpgram, 
' the computer system requires a voluminous library of transformer , modules. This 
- extensive library needs, significant, storage space .and regular^ maintenance, since 
for eyery new binary; specification which shall be; accessible a fiiU new set of 
transformer modules must be provided, in addition to the existing transformer 

30 modules. However, most of these transformer modules are not used frequently, so 
that their storage is not efficient. 
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Furthermore, these prior art transformer modules extend to the full functionality 
. of the software program to be translated from one binary specification to another. 
Due to the regularly wide functionality of software programs known transformer 
5 modules are rather voluminous and require, when they are activated, a significant 
amount of working memory and processor time from the computer system on 
which they are carried out. Furthermore, the complete translation of a software 
program is burdensome and time consuming, although it is in most cases unneces- 
sary for the specific-task to be accomplished. : 

Therefore^ it is an object of the present invention to provide , an efficient method to 
' enable a first software program to employ certain functionalities of a second .soft- 
ware prog?-am, wherein the first and' the second software program use different 
binary specifications?^ ' - .0 ' vk . ; ;: ; 

15 ■ '"^ ' '■ i "lo::^ 0 .r\ .3:^^jr;;^i; ^..--j^ ; /\ ^ . 

This objecf is solved by the <iMrese&t4Jiv^tion by providing a method for enabling 
*^ a Brst' isoftware progr^ using- a firskbinary/specification. to.employ a limited 
functionality of ai second^ software using a second binary -specification,* 

including the following stepisc ' q *■urr/^-;. ) : - . . ;^ ^ 

20 a) initiating the creation of a stub, which is able to transform commandis- relating 
to the limited functionality of the second program between the second binary 
specificatidn arid an intermediate binary specification, using a second bridge, 
wherein the sfecorid bridge provides a mapping of the second binary specifica- 
' ' ^ tion arid the intermediate binary specification, ^ : - ^ . . 
25 - b) initiating the creation' of a proxy; which is able to transform commands relat- 
ing to the limited functionality of the second program between the first binary 
specification and the- intermediate binary specification,' using a first bridg 
wherein the first bridge provides* a mapping of the first binary specification 
and the intermediate binary specification, and , : . 
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. .c)' initiating the arrangement of the .proxy and .the^stub relatively to the first pro- 
..,gram and the second [program in.a manner^allowing the first program to em- 
ploy the limited fimctionality of the .second program. . 

5 According to the present invention software programs are compiled executable 
programs. Software programs are initially written in a programming language, for 
example, C-H- on Java or an object model like Corba,, They are compiled, with 
-compilers corresponding to the programming :Janguage. However, for each pro- 
gramming language several compilers, may.be available. The binary specification 
10 . in:which a software program is able to^ communicate with other software programs 
depends on both, the prograntuning language and the jcompUer., This communica- 
tion language of a software program is the language referred herein as the binary 
specification used^by a software program,, for^ example, the first, the second and 
y the intermediate binary specification, 0 /-e;, : - : j- .- : . :^ : ^: : < . 
15 • ; \^ j: .-.^v .y^^ ^-s]. - j;^-::/r y:..".^ r ^ . 

„The intermediate binary ^specification;: s^^ the. binary specification into, and 

V firom which the commimication betA^eencthe. first/and th^;: second software ^program 
' will be,4ranslated. This intennediate:binary. specification may cbe,. for ;exampl^^ 
existing binary . specification iike the binajjy .specification; of: a specific compiler, 
20 but it is also possible that .tiiis intermediate-binary specifi.cation is a- suitable newly 
created binary specification, for example, a binary specification rwhich facilitates 
-! translation, into and fi-om it . r; c - ::r.: . c - ' ^ ; :: ^: > - 

In the scope of the present invention the two transformer modules, called proxy 
25 and; stub,; are created, on demand, that means if and when they:. are needed. This 
, creation . on demand wilb he initiated directly that means by the first softwa^e pro- 
gram.or.by means ;Of an initiating -fiinctipn. This creation on demand-is; considered 
; to be dynamic, so that the commands of the first software program may be dis- 
patched dynamically. The two transformer modules are at least able to transform 
30 .:conimands: Gon-esponding to a limited 'functionality of the second software pro- 
gram. Since the first software program employs in most .cases only a part of the 



26; 



Annex 

• -4- 

functionality of the second software program, the two transformer modules need 
to transform only commands which correspond to this Umited functionality. In the 
scope of the present invention commands are imderstood to be any kind of mes- 
sage initiating any kind of activity of a software program and which may be 
5 transmitted between the two software programs. 

In the scope of the present invention it is possible to insert fiirther modules, be- 
tween these two transformer niodules: These modules may be able.to intercept the 
commands. This interception may be >used, for example, to add security or ac- 
10 counting^ ftmctionality. It is also possible to use these two transformer modules to i 
synchronize the con^nauids of to use them for debugging. 

For the creation of the proxy and the stub mappings between the basic commands, 
on which all other conunands are based, of the two pairs of participating binary 

15 specifications are used. These pairs are the first binary specification and the in- : 
' tennediate binary specifiicatiori^anid'^fi^^cond binary specification and the inter- 
i mediate binary specification: These:mappings will be provided by the bridges and 
may be, for example, stored in a data base.^However, the bridges may also already 
be a part of the second software progr^ami In case these mappings cover the com- 

20 . plete 'fimctionality iof the relevant binary ^specifications - which is frequently the 
' case - only some piarts of the mapping may be considered during the creation of 
the proxy and the stub, since they relate to the above- mentioned limited fimctidh- 
ality only. 

25 - After their creation the proxy and the-stub'are arranged in a manner which enables 
the first software program to conuriuriicate with the second software program. 
That means a path of conlmimication inust be arranged from the first- software 
program to the proxy, from the proxy to the stub, and finally from the stub to the 
second software program. This route must regularly be accessible from both sides, 

30 that means from the side of the first software program as well as "from the side- of 
the second software program.^ - . . - . • . ^ . - ' . „ . * 
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In, order, to generate the stub the second 'binary: specification used by the second 
software program must be known. For this purpose, the first software program 
. : : may start the second software. program. This may^be done by the first program by 
•5 . means of a loader fimction which loads the second: software program. Loader 
fiinctions are well known in the prior art. A loader fimction is able to initiate a 
software program using a certain, binary specification on demand of another soft- 
ware program using a different binary .specification. :The loader fimction may di- 
rectly initiate the creation of the required stub or it may initiate that the second 
lOv, isoftware progTam,,or to, auxiliary program conmiunicatin the second soft- 

ware program creates the stub. This .is possible, if the loader fimction carries or 
'. ^ supplies by any .means the- infoimation about the limited ;fimctionality of the sec- 
; ond software program requested by the first software program, y 

15 . ^ The creation of the stub maj' be carried out j^yithe second. softwaraprogramor by. 

any sub-program of thei second software ^prog?:am,^^^^^ that this sub- 

. ..program, exists -already in the - secoudksoflwarev .program, lloweyer, this sub- 
- ; y;program may as: well be procured or^gsnerated by the second software program in 

response to arequest of the first so&waxfi,vi. v - ,3' - . . . , 

: \, After the creation of the stub, the .initiated second- software program .or its sub- 
: program creating the stub niay inform the first software pro^am-that the stub has 
been created. This may initiate the creation of the proxy by the. first, software pro- 
gram or any suitable sub-program, as it \yas. .described above for the creation of 

25 ..the stub. .X i;-;? v ^a^.^ -"^-^ . , .."-it::' ^;■ 

: ;;.The proxyiis created: by the. furst software program or a. sub-pro gram, -.a fimction 
thereof. The sub-program of the .first software program must consider the bridge 
. :for the transformation of the first, binary ^specification into the intermediate binary 
30 . specification and reverse and the requested limited fimctionality of the second 
software program. The information about the requested limited fimctionality is 
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generally available in the first software program, because the first software pro- 
gram requests this limited fimctionality firom.the second software program.. 

In order to . enable the communication between the first software program and the 
second. software program the stub and the proxy may transform any commands or 
other messages between these two software programs, as far as the proxy and the 
stub support this fimctionality. This requires: the above described arrangement of 
the proxy and the stub relatively to the first and the second software program. 

The present invention also provides a method for employing a limited fimctional- 
ity of a second software program using a . second binary specification by a first 
software program using a first binary specification; including the following steps: 

a) initializing the. limited r fimctionality of the second software program by the 
first software program, 

b) creating a^stub,; which Is^able^ to teansform commands relating to the limited 
. fimctionality of th6 second softwjareiprogram between the second binary speci- 
0 i fication and an mtermediate^Hbihary ' specif a second bridge, 
: . .v^herein the second bridge provides a mapping of the^secondibinary. specifica- 
tion and the intermediate binary specification, ; ~ 

c) creating a proxy, which is able to transform commands relating to the limited 
fimction^ity of the second soflAvare program between the first binary specifi- 

- cation 'and the iritermediate binary specification, using a first bridge, wherein 
: the first bridge provides a mappirig of the first binary specification and the in- 
' . . termediate binary specification, ^ . * . . - 

d) transmitting an command relating to the limited fimctionality firom the first 
software program to the proxy, 

;e).. transforming the command from the first binary specification into the inter- 
. mediate binary specification by the proxy, ^ . . 

f) transmitting the command transformed by the proxy from the proxy to the 
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g) transforming the, transmitted command from the intermediate binary speqifi- 
;,cation into the second binary specification by the stu^ 

h) transmitting the command transforined by the-stub from the stub to the second 
software program, - i ! , . 

5 i) carrying out the command in the second software program and generating a 
response for the first software program, 
j) transmitting the response, -being jn the second .binary specification, from the 

second software program to the stub,. ^ / , - .t 

k), transforming the response from the second binary, specification into the inter- 
10 , mediate binary specification by the stub, 

.1) transmitting tiie response transfomied by the stub from the stub to the proxy, 
m) transforming the resppnse^-frorn , the . intermediate binary specification into the 
first binary specification by flie proxy, >,_^ . . > , i - 

^ n) transmitting the response transformed by the proxy frpm the proxy to the first 
15 . * software program. r r/iV^^o^^f: -l.r-r. v /^^ ; / . 

*' ...... '-y. ^'jji .*o "jts/rc r;':.o'r! r, :i\ \ --^r * „ - 

The, transmissions bepveen, the prpxy :a^d^the s^^ and the software .programs, and 
the proxy or- Uie;Stub,; respectively,. may fbe effe^ by any suitable- means. It is 
relevant, however, that these elements, are, arranged so as to allow the commxmi- 
20 cation of the two software programs. 

Furthermore, a method for using a stub, which, is able to transform, commands 
relating to a limited functionality of a. second software program between a second 
r binary ^ specification and an intermediate binary, specification, using .a second 

25 bridge, \yherein the second bridge provides a mapping of the second binary speci- ; 
ficatipn arid the intermediate binary specification, is provided for enabling a first 
. software program using a first binary .specification tp employ the limited func- 
tionality of the second software program by further-.using a proxy, which is able to 
transform commands relating to the limited functionality of the second software 

30 program between the first binary sj5ecification and the intermediate binary specifi- ^ 
cation, using a first bridge, wherein the first bridge provides a mapping of the first 
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binary specification and the intermediate binary specification, wherein the proxy 
and the stub are arranged relatively to the first software program and the second 
software program in a mahiier allowing the first software program to employ the 
limited fiinctionality of the second software program. 

Also provided is a method for using a proxy, which is able to transform com- 
mands relating to the limited fiihctiohality- of the second software program be- 
tween the first binary specification and the intermediate binary specification, us- 
ing a first bridge, wherein the first" bridge provides a niapping of the first binary 

10 specification and the intermediate binary* specification, -for enabling a first soft- 
ware program using a first binary specification to erhplby the limited functionality 
of the second soflware'program by fixrther tising a^stiib, which is able to transform 
commands relating to a limited fimctiartiility of a second software program be- 
tween a second binary specificatioii arid binary specification, us- 

15 ing a second bridge, wherein the second bridge provides a mapping of the second 
binary specification and the intermediate binary specification, wherein the proxy 
^ ^and th^ stub are' arranged^reia;ti wly* td^ ffi^^^ soflwai-e program and - the second - 
^ software program ih^a iriantfef' allowing first software program to^^ employ the 

* "limited fiinctionality of the secbhdsof^ - " r.- : 
20 . : . ^ . 

In the scope of the present invention there is also provided a computer program, 

* alsb' referred to ais a cdniputer prograiti' product,' for carrying but the rnethod of the 
present iiivehtion; A computer prograni -product comprises a medium configured 
to' store or transport computer. readable code, or in which computer readable code 

25 may be einbeddedv Sonie examples program product are: CD-ROM 

disks, ROM-caards, floppy disks, magnetic tapes, computer hard drives, servers on 
a network and carrier wave's and digital •sisals transmitted over a feleedrhmimi- 
cation link or network connection. ^ - - 

30 Such'computer program may be stored on any data carrier, such as/ for example, a ' 
disk, a CD or a hard disk of a computer system. It is further provided a method for 
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/using a computer system, including standard computer systems, for carrying out 
* tbe present inventive method. Finally, the present; invention relates to a computer 
. -.system comprising a storage medium on which a computer program for carrying 

out a method^ according to. the present invention may be stored. 
5 \ . . - - . 

The present invention can be described . exemplary along the following figures, 
which shows: , : . , 

Fig. 1 : schematic representation of the inventive method in oyerviev*^^ 
Fig. 2: flow chart: initial conununication of a first and a second software 
10 . :■. program -yy ■ - ^ 

.Fig. 3: • flow chart: creation of a stub * 
. Fig. 4: . flow chart: creation of a proxy - 
; . Fig. 5: flow chart: arranging fL'stub and 

. Fig. 6: u schematicrrepresen^iidn>o,fi a- computer jsy 
15. . ' scope ofthe present-invention v).,,^ > . :--]r-\ 

^ ; : r Fig.. 7: : representation of a ^sUef^t f 

the present inyentionfo^er:;,u. t. *y ^ 

Fig. 8: flow chart: caUing of a stub 
: . : 1^ A Fig.. 9: . ;flowxhart:fcalling ofithC:secpnd program / 
20 . t.r: /' Big. 10: .flow chart :Mnding^^^ : „ • - 

Fig. ll:rflow chart; callings the, second software program from a, first soft- 
^. ware program via a prQxy:and a stub , ^, .•^.v: ;■ ; 

. Fig: 12: flowxhart: transforming ^and transmittiiig a- command from the 
. c ; ; 1. first - software prograni jto the second so ftware program ; ^ , 

25 Fig; 13: schematic representation .of -^an i a. 

stub and a proxy . 
Fig. 14: flow chart: use of an interceptor function in an arrangement of 
• : stub and proxy > - , , . ^ - . . ; ' . i - ^ 

30 First,, reference- is; mad^ to Fig. 1. A first software program 1, created with any 
V / convenient programming language, for ex£m C-H-, and compiled with a certain 
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compiler for C-H-, uses a first binary specification. This first binary specification 
depends on both, the programming language and on the compiler. The first soft- 
ware program 1 may be, for-example, able to present numbers in graphical form. 
In order to calculate the ex^ict dimensions of the graphs the first software program 
5 1 may want, to employ a second software program 2, created with another pro-, 
gramming language, for example Java, arid compiled by using a certain compiler 
for Java. This second software program 2 uses the second binary specification for 
communication. 

10 The use of the second software program 2 by the first software program 1 requires 
its initialization, for example, by calling a loader fionction 5. The. second software 
program 2 may then initialize its sub-program 2a for creating the stub 4. The sub- 
program 2a must consider the limited functionality in order to arrive at the desired 
stub 4, namely a module for transfonniii and responses relating to the 

15 requested limited fimctionality. Raised J bri - this, limited fimctionality, the sub- 
program 2a selects the relevant mappings of the bridge 7 between the second bi- 
nary specification and the intermediate binaryispecification. ^ 

The first software program 1 rhay- coitespondingly initiate a subrprogram la to 
20 create the proxy 3 in a similar way, by J employing the bridge 6 between the first 

binaiy speeificatiori arid the intermediate binary specification. This sub-program 

la may be informed about the limited functionality^ from the first software pro- 
- " gram 1;- However, it may also know this limited fimctionality from the second 

software program 2 by communicating via the comniunication channel 8. This 
25 -channel 8 may be "any suitable real-or virtual connection which allows the transfer 

of data. s ^ - 



After the stub 4 and proxy 3 have been created they are arranged so as to allow the 
communication between the first software program 1 and the second software 
30 ■ program 2. Once this arrangement -is ^effected the first software' program 1 sends 
the command to be transformed to the proxy 3. The proxy 3 may transform this 
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command from :the. first binary specification into tiie intermediate binary specifi- 
cation. This intermediate binary-specification: corresponds,, for example, to. the 
^binary UNO specification. The proxy 3, may traiismitjhis command in the inter- 
mediate binary specification to the stub .4. The stub 4 may^ transform the conunand 
from the intermediate binary specification into the second binary specification and 
may transmit the command then to the second software program 2. 

The second software program 2- inay , execute the comjtnand, for example, the 
command to calculate the dimensions; of a graph and may generate a response. for 
the first software program L This rejsponsp may be transformed and transmitted 
by the stub 4 and the .proxy -3 from the second softw^^^ 2, to the first 

software program 1. . ^ ^.>^o! k:::: . : : . : - 

The arrows shown in Fig. 1 between thejfirst soflwarevprpgrsum 1, the proxy 3, the 
stub 4, the second software program 2 and the loader function 5 show the possible 
routes of ,comm\micati on. Theirarro^s bety/een the proxy 3 ^d the bridge , 6 . and 
between the stub 4 and the bridge 7Treprg^^^^^ the eontributipn,of;the bridges 6 and 
7 to the; creation .qftthe proxy 3 and tiie stufe 4, respectiyely;- : ; ; r ; - 

Fig. 2 represents an, example for.the^nitial commiinication o first software, pro- 
gram 1 and.a second software, program 2.'-The initial cpmmuni.cation between the 
two software programs 1, 2 is carried , out, before the creation pfthe Stub .4 and of 
the proxy 3 is initiated.^ Due to the different binary specifications used by the two 
software programs 1, 2, namely the firsthand the second binary specification, this 
initial communication will regularly be .extremely limited. It may: be. effected as. 
explained exemplary in the following. 

In a first step 20 the first software program 1 may call a loader, function 5 for the 
second software program 2., The loader -function 5 may be any; known loader 
- function for this second software progrsmfi 2. A loader function for a program is a 
software module which Vwakes up this program so that , it carries out certain 
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fiinctions. Herein, the loader function may be addressed in one binary specifica- 
tion and may wake up a program using a different binary specification. However, 
the loader fimction is not suited to provide any detailed communication between 
programs using different binary specifications. 



The loader function 5 may be used by the first 'software program 1 firom the be- 
gimiing. This is the case, if the first software program 1 knows or assumes that the 
second software program 2 does not use the same binary specification as itself, 
namely the first binary specification; If this knowledge is not present in the first 

10 software program 1, -it may simply try: to- call the second software program as- 
" suming that it will understand the first bihaiy specification. In this case, the first 
software program 1 may only employ the loader fimction 5 if the direct commimi- 
cation with the second software program 2 fails and a corresponding message is 
^ returned to the first softwiare pirdgrain*!-^ - - * 

15 -^v ■• . i .}\ t:h btiJi ^. -r .. . • ■ % 

^ In the ^calling step 20,the first software program t informs the loader fimction 5 
- • about .the- lirhlted flmctiohality re^ from the second software program 2. 

Therefore, the loader fimction 5 niust Be- suited to receive and carry this informa- 
tion. In order to provide this infomiation to the loader fimction 5 the first software 
20 ^- progrark 1 may haiid over to the loader function 5 the command to be' carried out 
by the second software program 2, so that the second software program 2 may, on 
receipt of the call of the loader fiinction' 5 decide itself which fimctionality is 
> heeded, or the first software program-1 -may -provide the -loader fimction 5 directly 
with the description of a limited fimctionality of the second software program 2 
25 '■>^ which will be required by the first software program 1. 

In step 21 the loader function 5 contacts and initializes a reception function of the 
second software program 2 to be able to transmit in the next step 22 its informa- 
tion about the limited fimctionality 'required firbm the second software program 2. 
30 In the next step 23 the second - software program 2 analyses the information re- 
ceived from the loader fimction 5 regarding the required limited fimctionality. 
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After the analysis of the limited functionality required the second software pro- 
• gram 2 initializes the creation of a^stub 4. . ..,r,,;iv 

Fig. 3 shows the creation of a stub 4: The stub 4 has the task to transform com- 
5 mands sent by first software program .4 to the second software program 2 from the 
intermediate binary specification into the second binary specification used by the 
second software program 2 and to transform responses sent by the second soft- 
ware program 2 back to the firstsoflware prograni 1 from the second binary speci- 
fication into therintermediate binary, specification. Furthermore, the stub 4 may be 
10 ' assigned the task to: transmit: the; transformed .commsuids- or responses to the re- 
cipients, the second sofhvare.prograin 2. prithe^proxy 3, respectively. 

In step 30 the second software program 2 may initialize a sub-program 2a for cre- 
ating the stub 4. This sub-program 2a may be an integral part of the second soft- 
15 - ware program 2 or it may be as .weH^a sep^ate^ independent software module 
which can be used by this and: pot^tially tany other second software program 2. 
1 . Accordingly, the sub-program :2a/may fceystprjed on the.cpmputer systerii^or .stor- 
. age device on which the second software, prpgr^,^^ is* stored,. However, the svib- 
r program 2a may' also be stored on anpth^ri computer system or stoirage. device to 
20 . which the second .software program t2bas/ access. ^- ■ : . 

In step 31 the sub^program 2a receives, from the second soft\yare . pro gr^a^ 
scription of the limited functipnality,required from the second software program 
... 2. Then, in step 32 the bridge 7 between-the second binary specification- used by 
25 the second software program 2 and the. intermediate binary, specification is con- 
tacted. This bridge 7 provides a mapping of at least all basic commands between 
the mentioned two binary specifications^ It may be stored at any place accessible 
for the sub-program 2a. In many cases there may exist a library with bridges for a 
' . number of second binary specifications, .assuming that- the intermediate, binary 
30 . , specification^used would be the same for . alL . . 
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From the selected bridge 7 the sub-progrSLm 2a chooses in step 33 the mappings 
necessary to use the required limited functionality of the second software program 
2. This means all transformations, but not more than these, must be selected which 
are required to transform commands and responses which could arise when using 
the relevant functionality: Finally, in step 34 the sub-program 2a creates the stub 4 
based on the chosen mappings. : . - 

Fig. 4 represents in the forin of a flow chart the creation of the proxy 3. The proxy 
3 has 'the task to traiisform- conimands^ to between the first binary 

specification and the interriiediate binary specification.^ It is insofar similar to the 
stub 4 which has, as it was described -above; the task to render these transforma- 
tions between the second binary specification and the intermediate binary specifi- 
cation. '■- ^ ^ .. . > . y. : n:^ : . ::; 

In step 40 the first software program tm^y initialize a sub-program la for creat- 
- ing the jproxy 3: This sub-progjam^i^^^ part of the first software 

^ prograrh- 1, but may as well be separate and independent firom it. The sub^program 
la niay be accessible for a larger number of first software programs l. In step 41 
the siib-programnk receives from- fhb^^Tirst software program 1 information re- 
garding the limited fiinctionality required firom the second software program 2. 
This infomiation may be provided by passing on the actual command the first 
software program 1 plms to send to the second software program 2, so that the 
' siib-prograrii la rhay derive fi-om this command the information about the limited 
•fiinctionality, or^the-first software -program 1 may provide the sub-program la 
' with a description- of the limited fiinctionality. 

In an alternative embodiment the description of the liinited functionality may be 
received firom the sub-program 2a for creating the stub 4. The sub-program 2a has 
the required description, because it has to create the stub -4 according' to the- same 
description. The description may be exchanged between the sub-program 2a and 
the sub-program 1 a by any suitable means of communication. 
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In yet an alternative .embodiment the description of, the Hmited fiinctionaUty of the 
: .second software program 2 may be derived directly, by mapping the stub 4 into the 
first binary specification, in order to create a proxy. This is possible, because, the 
5 stub 4 reflects the required limited functionality in listings between the second 
binary specification and the intermediate binary specification which are necessary 
for the transformation of commands and responses. Therefore, the intermediate 
..binary specification side of the listings: of the stub 4 may be taken. as the starting 
point for the creation of the pi:oxy 3» which is completed by adding the corre- 
10 V spending parts of the listing in; the, first: binary specification, as will be explained 
' ,i-below_ * ^ n. :i; ^ ^ , ^ ^-r , . ^ ,^ 

In step. 42 the sub-program la contacts ithe >ridge 6, which provides a mapping of 
basic commands of the first binary specification and the intermediate binary 
15 ./ specification, and builds, m step 43,- the desired prox}^^ \- rv^r-, , > ■ 

v.. The proxy 3 and .stub;4 arcithen > arr9nged to allpw">tlie desired ppmmimicati on 
: between the first software program -lianM. the second spftw^are program 2, as it will 
f.Aube described in the following along the flpw chart of Fig;v5, T^^ 
20 proxy 3 and stub 4 requires that:the^path:.of exchanging trjmsformed commands 
and responses between the proxy 3 and the stub 4 is defined. 

. Therefore, iii step 50 the second software prograin 2. infpnns^^^ t^ 
program 1 about the address information necessary to, contact the stub 4 
25 communication line 8. The communication line 8 may consist of a simple data 
. line for transmitting binary , address information which can be ^understood from the 
- first: software prograrn 1 without being able to use. the second binary specification 
in w^hich the second spftware.prpgram 2 coriimu : ~ ^ - . 

30 . The first software program 1 provides, in step 51, the sub-program la with this 
received address information, which,. in step 52, is passed on to the proxy 3. The 
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proxy 3 then contacts, for the first time in step 53, the stub 4, the address of which 
is now known. In step 53: the proxy 3 will also transmit its own address informa- 
tion to the stub' 4, thereby allowing the stub 4 . to contact the proxy 3. Herewith, the 
proxy 3 and the stub 4 are arranged for commimication, that means they can send 
and receive commands and responses to commands. This arranging step is also 
referred to as binding. ,^ 

Fig. 6 shows a cotnputer system 60 which may be used in the scope of the present 
invention. The computer system 60 comprises an i-/o-interface 61, a central proc- 
essing unit (GPU) 62 and memory 63. It is connected to an external memory 64 on 
which mass data may be stored as well as software programs. Furthermore, the 
computer system 60 is connected via the i-/o-interface 61 to an output device 65, 
for example, a screen, and to aii input device 66, for example, a keyboard^: 

The inventive method may^ be^ applied 4ri the shown standard computer -system. 
The first software program 1 and the second software program 2 may be stored in; 
the internal memory 63 c^f ^the computer system -60, as well vas on its external 
rheniory 64^- It is also possible that 6rie of the programs is stored ori the intemal 
memory 63^and the other is stored 6ti the external memory 64.". The proxy 3 and 
the stub 4 may be created by means of the CPU 62. 

The method according to the present invention may also be implemented and used 
on more than one computer^system, for example, in a tietwork or in a client-server 
' system, as it is s&bwh* exemplary in Fig. ^7. - - 

Figv 7 shows a client 70 which is connected to a server 71. This connection may 
be a data line 72, including any kind of permanent or temporary network, like, for 
example, the intemet. It 'is understood that, instead of only one client, there may 
be a large number of clients connected to the server. In the scope of the present 
invention the first software program 1 may, for example, be stored on client 70, 
while the second software program\2 may be stored on server 71: The exchange of 
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^ commands and responses may be effected via data lixie 72. -For example, the 
- bridges 6 and 7, as well as any other potentially needed bridges may be stored in 
one or more libraries on the server 71. The sub-programs la and 2a may also be 
stored on the server 7L In case the sub-program la is needed the client 70 may 
5 request from the server 71 its transmission via data channel 72. 

It is understood that the present invention may also be implemented in a variety of 
embodiments. Iri the following one* embodiment of the present invention- is de- 
r " scribed in more-detail along Figures.^^o 1 1 and Tables 1 and 2. ' 
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Creation of stub and proxy: 



— In response to a call of a first software program a proxy and a stub will be created 
in the so-called proxy factory and the stub factory, .respectively. In order to create 

15 a proxy and a stub three tasks have Mcbe cam out. First, the first software pro- 
gram using the first binary specificatibnvhasito be .enabled to coiimiunicate with to 

the second software program usmg -|d^^ 

' ' s,tub -factory has ,tO; create a uno- interface iimplemen^^ considering the second 
binary specification based on the liinited.fimctionality wM 

20 rected to the second software progrtoi to this second .software progr^^ This 
uno_interface is program code which is defined for the limited functionality. For 
the generation of the uno_interface implementation the stub factory, employs in- 
formation in the form of a type description." This im6_interface implementation is 
also referred to as the stub. Third, the proxy factory has to create a uno^interface 

25 implementation for the first binary specification. The pro'xy factory generates its 
imo_interface_ implementation based orir the information of the type description. 
This uno2_interface implementation; is refenre , : 

The knowledge of the type description is necessary to create the stub and the 
30 proxy, as described. This type description is the full description of the limited 
functionality, also, called interface. It contains the information about the required 
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limited functionality of the second software program which shall 
first software program. The type description may refer to different 
- Table 1. r -' * ' - 

5 Table 1: 



TypB \UNO !C++ 


Java 1 


Byte ISiqned 8 Bit [Signed 8 Bit 


— — -J Q a:# 1 

dignec o uii i 


fehort feiqned lSBit ISianed lB Bit 


Signed 16 Bit I 


Ushort [Unsigned 16 Bit ' Unsigned 18 Bit 


Signed 16 Bit | 


tong [Signed 32 Bit [Signed 32 Bit 


Signed 32 Bit I 


Ulona tUnsianed 32 Bit * ' * Kjnslgned 32 Bit ' 


Signed 32 Bit I 


Hyper iSiqned 64 Bit 


Signed 64 Bit 


Signed 64 Bit 1 


Uhvoer lUnsigned 64 Bit - - 


Lincigned 64 Bit 


Signed 64 Bit | 


Float 


Processor dependent: Intel. Sparc = 
EEE float 


Processor dependent Intel. Sparc = IEEE 
loat 


IEEE float 


Double 


Processor dependent Intel. Sparc = 
EEE double 


Processor dependent Intel, Sparc = IEEE 
double 


IEEE double 


Enum 


Ttie size of an machine word. Normally 
this is the size of an integer 


The size of an machine word. Normally 
this IS the size of an integer 


All enum values of one enum declaration 
are static object of a dass Each object 
contains a 32 bit value which represents 
the enumeration value. 


{Boolean 


1 Bvte. 


1 Bvte ..... - 


Boolean 


Char 


16 Bit on WNT, W9^, W98, 6s2, 32 Bit 
on Unix v 


16 Bit oh WNT. W95. W98. Os2 32 Bit ort 
Unix . 


Unsigned 16 bit (char) 


String 


A pointer to a strxicture whic^t- have the* 

following members- 

orig refCbunt:t :CjO 

ong length, 

wcharjl buffer( .1:. v 

The string in buffer ic 0 taoninated' ' - 

rhis is the rtljwString structure in the 

rtl-library - . . , - . ^ ^ 


■~T — rr"T'~'"~^~T~~~"'n^'~~'*~~^ ' 

A pointer to a structure which have the 
following rnembers.- 

idng rSfCourit: * ' ■ ■ ■ ' ' - ' • ^ - 
long length; 

wchar:_t puffer! v;]: ^ • - 
The string iri buffer Is 0 terminated. This is 
the rtl_wString structure In the rtl-library 


Java lang.String" 


. Structure ' 


The structure contains the members in 
the order of the declaration., The_ _ 
memory layout iis describeil at t>^ ' . ' , 
beginning of this chapter. 


The structure cbritairu the members in the 
order of the declaration. The memory 
layout 4s'de&crit>ed at the beginning of this 
chapter. 


A class which is derived from 
Java.lang.Object^ and contains the mem- 
bers in the spedfied lorder. 


Union. 


The sizejs 4:+/slze of thejargest type,- 
In front of the union members are a 
tong value (nSelect) which describes 
the posltion'of the valid niembiBr (0 is 
the first). 


The' siie is 4^+'Size of the largest type. In • 
front of the union members are a long 
value (nSetect) which describe the posi* 
tion of the valid member (0 is the first). 


Not spedfied yet 


Sequence ^ 


A pointer to a structure which has the *, 
following members 
void,* pElements. 

lorig hElements. - ' • - ' - - 
long nRefCount. 

The.pElements are; a memory area -that 
contains nElerhents elements 


A pointer to a structure which has the • - 
following members' 
void • pElements; 
long nEIemenls; - * 
long nRefCount; 

The pElements are a memory area that 
contains nElerhents elements ' 


It is a normal Java array: . 


Exception 


Looks tike a" structure ■ • 


Lodkslike a structure 


A dass which is derived from 
JavaJang.Exception* and contains the 
members in the spedfied order. 


Interface 


The interface is a pointer to a function 
table, which contains 3 functions. 


It is -a. pointer to a C++-Class which im- 
piements first the virtual methods query- 
Interface, acquire and release 


It is a nonmal Java Interface 


Any 


This is a structure that contains a 
pointer to a type description The 
second member is a pointer to the 
value stored in the any 


^ - » - - ' |A dass which is derived from 
This is a structure that contains a pointer Ljava-lang ObjecT. The members are a 
to a type description The second member &ass, which describe the type of the value, 
is a pointer to the value stored iri the any [A second member which is the value of the 

bny. 


Void memory representation 


No memor/ representation jNo memory representation 



Many of these types are self-explaining and known iri the art. Nevertheless, the 
most relevant types of the type description will be explained in more detail below. 



be used by the 
types shown in 
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"Interfaces": All interfaces employed in connection with the present embodiment 
are derived from a Super-Interface. Each interface contains. at least three methods. 
The two methods "acquire** and "release** are necessary to control the lifetime of 
the interface. The third. method "querylnterface** is used to. navigate between dif- 
ferent Interfaces- A XInterface includes only these three .methods. AH other inter- 
faces are derived from this XInterface. The methods and fimctionalities requested 
by the first software program will be part of the interface. 

In Java, for example, interfaces are^^mapped to Jaya interfaces which could be 
normally implemented. The methods acquire and release are not mapped to the 
Java program since this methods do. not , exist in Java, The lifetime of the proxy, 
the stub and the relevant information iiivthe second program will be controlled by 
a garbage collector. The programming;!?^ Java delivers basic ^types.b^^^ 
and non-basic types by reference. All calls are specified by value except inter- 
faces. So in Java all non-basic typps tej^iimed or jdeU^ 

are by value, which means that the implementation must copy it before return or 
deliver. 

In C++, for example, interfaces are mapped to pure viiinuial. ^classes. In order to 
automatically control the lifetime of interfaces a template called "Reference" will 
be, used. All retum, parameter .and member, types ^ are "References** (e.g:: Refer- 
ence< XInterface >). The "Reference** ^acquires the, interface when it is con- 
structed and releases the interface ^Yhen itis destructed. , ; 

"Structure": A structure is a cpUectipn of elements. The , type of- each element is 
fixed and it cannot be changed. The number of elements is -fixed. . 

"Exceptions**: An exception is a program control construct beside the normal 
control flow. One major feature of exceptions is, that it is simpler to implement 
the error handling. Exceptions are similar to structures since they are also a col- 
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lection of elements and each type of each element is fixed and cannot be changed 
and the number of elements is also fixed. An additional feature of exceptions is 
that they can be thrown by a method. All exceptions which can be thrown by a 
method must be declared at the method, except for the called "RuntimeException" 
5 which always can occur. All exceptions must be. derived firom "Exception". If an 
exception is declared at a- method it is allowed to throw all derived exceptions. 
- The caller of a method must respond to this behavior. 

In Java, for example^ all exceptions are derived firom the "java.lang,Exception". 
10 -The exceptions are declared at the methods i ' 

In C+-+-, for example, the exceptions are generated as structures. An exception is 
thrown as instance (e.g.: throw RuntiriieExceptionO). At the othei side the excep- 
tion should be caught aisreference:(v..cMch^iintimeException }). 

•*TJni6n'^ A union contains one el^^^ union specifies the 

possible types.- -^^^---^ vjrr; ro^; .:r^ _ ; r;, 

"Array*: An array contains any number of elements. The type of the elements is 
20 fixed* and cannot be changed. rf:..^^^:-: - .. ; ..: r r / 

"Ah/'i An any contains one element. All t>pes of elements are possible. An any 
contains a reference -to the value and the- type descriptioh of the type. With the 
type description the bridge can transform the value, if necessary. 

25 

In Java the any is, for-example, represented by the class "Any", which contains a 
class as type description and a' "java.lang. Object", which is the-value. The .basic 
types are wrapped to their proper classes. For example, a boolean value is an ob- 
ject of the class "java.lang.Booleah",wWch contains th^ 
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In C-Hh the any is represented through the class "Any". Each type generated by a 
. C-Hr codemaker implements an function "getCppuType". This function is used to 
* implement the template access operators "<<=". and "»=". These operators insert 

and extract the value of the any. g : 

"Sequence": A sequence is a generic data. type. It contains the number of elements 
and the eleriients. :In Java the specification of :an, array fiilfills this specification. 
This is not true for C-H-. The^arraj' in C-H^.-does not contain the number of ele- 
ments. It is not possible to return a C-H--array, e.g. Cbar[] getNameQ is not possi- 

10 ble. It is difficult to manage the lifetime between the called and the caller, if only 
a pointer is retumed. Therefore, inrG++ a sequencers a template with the name 
; ;*Sequence'\ The implementation icontjains^ a pointer to. -a structure which contains 
a pointer to the elements, the number of elements and the reference;COunt. So it 
. : holds the binary specification. It is cheap/to copy, this sequence; because only the 

15 reference:count is increnrientedi, .n^.?^,^^ ^'f: r i ^ ; 

The type description may exist or it may be runtime created. Each existing type is 
..i- stored in .a type repository along .wifer the,, cor^^ type , description/ The 

' J - types of the type description are accessible ;thrp^igh,- the full name of each type in 
20 ^ the type repository. For .example, thCifuU name of the, type. "Xinterface" niay be 

"com.sun.star.XinterfaGe"., . ; ^ . - . ■ . - 

In a type repository the types needed for any type description are stored in any 
appropriate way. If the API (application, program interface) of the type repository 

25 is c-style, it is directly, :that means .yia a binary representation, accessible from ■ - 
many binary specifications,,and, it :is: quickly transferable. Since the type descrip- 
tion of each element may be .xised during the generic marshaling of a call, the ac- 
cess performance of the type repository API is critical. Therefore, it is useful to 
use c-style structures, which describe each type. In addition, there may be inter- 

30 - . faces declared which .specify^the access to the type^-repository. The module of this 
interface is "com.sun..star.typelib". . , . - 
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All functions or type deelarations have the prefix "typelib_". All elements are 
reference counted. 'AH - elements^ start with the structure "type- 
lib_TypeDescription". It is possible to cast all descriptions to this type. The fimc- 
5 tion typelib_typedescription_newInterface will be used to create an interface de-": 
• scription. The descriptions of structures, unions and sequences are created with 
- the function typelib_typedescription_riew. The description of the base type is ini- 
tially part of the type repository. The function to get a type description is 
typelib typedescription getByNamej 
10 - ■ ~ ' , ; 

The Java API to the type repository is different for two reasons. First, Java cannot 
' access the binary representation of the type' descriptions directly. Second, the Java r 
runtime systeni provides an API (cofe reflection) similar to the type repository 
API; Unfortunately, the features "ilnsx^ed", "oneway" and "out parameters" are 
15 missing in this API. For this reason, additional information is written into the 
classes. 

The representation of the types depends dni the hardware,' the language and the 
operating system. The 1?iase type ns^ ^wapfped, for exainple, if the processor has 
20 little or big endian fofmat. The size of the types "may vary depending on the proc- 
essor bus size. The alignment is processor and bus dependent. The alignment of 
the data structure is defined through the following algorithm: 

Structure"^ members are stored sequentially in the order in - 
25 V : . . . which they are -declared. Every data object has . an alignment- : 
^ requirement . For structures, the requirement is the largest of its 

- members. Every object is' allocated an offset so that offset % : ' 
■ alignment-requirement = d ' ^ • - - ^ 

30 If it is possible that the maximum alignment can be restricted (Microsoft G/CH-+ 
compiler, IBM C/C-H- compiler) than the size maxinium alignment is set to eight. 
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.'Under this condition :the alignment is §et to min( n, sizeof( item ) ). The size is 
. round up to the largest integral base type. 

For the Microsoft and IBM C/C-M- compiler the alignment of structure is set to 
eight using the **#pragma" statement. Table 1 shows the binary UNO, C+-t- and the 
Java types. ^ 

In order to address the proxy factory to generate the proxy the first binary specifi- 
cation has to be, denominated. This-willbe a string, because it is extensible and the 
/risk of double names is low^ Then a tool for selecting the desired bridge is called. 
The first parameter for this tool , is the "first binary^specificatipn*' and the second 
parameter is the intennediate binary -specification; "UNO". Then a function is 
called for selecting the desired mapping pf the bridge. The name of the function 
is, in this example, "getMappingFactqiy'VA ca^^^^^ in "objective c" 

will be "getMappingFactpry(t-objectiye£c':\^*h^^ The implementation. ^o 
fimction will search a shared library named "objective_cuno" to find the right 
.library that j^ontains the proxy factory: Jji Java the tool may search for a; class of 
name **olyectiye_cuM^ - ^ t^iv a : r^ J; . i \ ■ ^ • 

In order to create a stub merely the parameters of the fimction have to be changed, 
in pur example, to "getMappingFactory("uno", "objective_c")'% A stub imple- 
ments the uno_interface. In the dispatch fimction the stub must/ c^^^ 
method of the original object. This is simpler in a programining language like 
Java, which has a , "core reflection APF', than in a progran^ language like 
C-H-, which has no binary standard and no API to call virtual methods. 

In creating a proxy, the proxy factory must generate .method code to implement 
each method specified in the interface-to be created. The only information to do 
this is a type description of the interface. For example: In Java (1 , 1) a binary class 
file (*.class) must be generated and loaded with the class loader. In the absence of 
a loader which can directly load binary classes a loader has to be provided. In Chh- 
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virtual method tables must be 'generated which delegate each call to the 
xmo_interface. In the absence of a binary C-h- specification individual compilers 
(version, switch,...) may have to be explored in order to implement this. 

5 The proxy and the stub factory employ bridges for the generation of the proxy and 
the stub, respectively. A bridge implements infrastructure to exchange interfaces 
between two environments and is bidirectional. 

An' environment contains all objects \Vhich'suffices the same specification and lies 
10 in the same process address space. The erivifonihent is specific for a programniing 
language and for a compiler. For example, ail object resides in the "misci" envi- 
ronment, if it is implemented in C-M-^aiid coiiipiled with the Microsoft Visual C-H- 
conipiler. It may also be session specifi(5-f6r some reason, e.g. when running mul- 
- tiple Java virtual'maeMries in one process these virtual machines 

15 have to be distinguished. HoWevfei-,-tiiis^^ ' 

' Rtegiilarly, the eriviroriment is the-drek iii 'which the same binary specification is 
employed. Therefore, the first software program and the second software program 
belong to different environments. 

Each biidge is impremerfted in a separate shared library. The name of the library is 
^a* connection of two environment narh^s' with an underscore (*_') between the 
naihes. Each bridge library exports two functions called *\mo_ext_getMapping" 
^ and *^ino_initEnvHronirienf'. The first fimctibn is called to get the mappings. 
25 ■ ■ - - - " ' - - : ~' • - - ^: 

In order to get a mapping uno_getMappingO has to be called. There is also a Ch-+ 
class called cppu_Bridge which can be used with the source and destinatiofi envi- 
~ ronment names. The uno_ext_getMappingO ciall then receives its source and des- 
tination' environments. -The bridge -library cannot be unloaded while -any code of it 
30 is still needed. So both mappings and any wrapped interface (proxy) that is ex- 
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ported needs to modify a shared library .wide reference count. If the shared library 
can be unloaded the reference count goes to zero. : . 

The intention of an envirpninent structure is to provide common functions like 
5 acquirelnterfaceO and to know all proxy interfaces and their origins. This is spe- 
cifically important because of the object identity of an interface. The proxy, the 
stub and the second program are defined-to provide the same instance of the Xln- 
terface any time it is qUeried for it. This is important to test, if two interfaces be- 
long to the same object (e.g. testing the source of an incoming event). 

10 ; ■ - /~ : ' : '1; .\ - r'" 

When interfaces are mapped aiouiid some environments in space, they must pro- 
vide the same XInterface iii icach' eh\dronm equal XInterface 
pointers). r - . r ; 

15 It is not recommended^ to bifly.keept^jn issue. It is well 

recomrnended to reuse any interface^i.k fejectiiigy^^ inter- 
faces as often- as possible^ because each-constructed proxy interface leads to an- 
other indirection when called, and-there will of course be many interfaces. 

20 . - So an .environment knows, each wrapped interface .(proxy) ri^^ in it and the^ 
origin of each of these interfaces. Table 2 shows the representation of an envi- 
ronment. _ _ " :* T-- *— ' ^* C 

Table 2: . . : . J-^ '-:\^ 

25 struct uno_Environment 

/** " ■ ^ J ' ' 

* a name for this environment 

*/ .. .. - ... ^^ . 

30 u rtl_^String *.pName; . si-,.-:--: - , 2 ' ...j >i 

/** - r 

* a free -context- pointer , -..that . can be used for specific, classes of envi- 
ronments, : ^ ■ .* ' , • u - - 

* e.g. a jvm pointer 
35 ^ ■ . — • 

void ♦ pContext; • 
/** , - - 

♦Acquire? this environment;- 

*<BR> I 
40 * ©param pAccess this access interface 
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*/ . 

void {SAIj_GAI*L acquire) ( uno_Environment * pEnv ); 
/** 

* Releases this environment; 

* last release of environment will revoke the environment from runtime . 
*<BR> 

* Sparam pAccess this access interface 

void '(SAL_[_CALiL ' * release) { uno_Environment * pEnv ) ; 



•/*• ■■ •• - 

* Tests if two environments are ec[ual . 

*<BR>, . . . : : - " - 

* ®param pEnvl one environment 

15 ' * ®param pEnv2 another environment . . i . 

^ " ^/ ' ' • ' , - - ■ 

sal_Bool {SAIj_CAIiL * equals) ( const uno_Enyironment * pEnyl, 

~ ■ ^ * * const iino_Environment * pEnv2- ) ; 

20 * /** . ^-^ - : - v / . : - 

* You register internal and external interfaces via this method. 

* Internal interfaces are proxies that are used in an environment. 

* External interfaces are interfaces that are exported to another 

* environment thus,. providing an object identifier for this task. 
25 - ■ '*« This can' be called an external' reference . -* 

* Interfaces are held weakly, at an environment; they demand a final 

- * revokelnterfaceOcal-l for each interface that has been registered. 
*<BR> 

* ©par am pEnv this environment 

30 * ©param pplnterface inout parameter for the registered interface 

* ©param ppOId inout parameter for the corresponding object id 

* ©param pTypeDescr type description of interface 

* ©param accg[uire ftinction^tq.^ acquire, an interface; 

■ * ' ♦'this fimct ion provi!de 9* a'' boolean "return ^ . 

35 . * value to signal if. the acquisition was. successful (necessary for 

* proxy interfaces-)-' ''"^ --^.J .^--^ .1 ' ; ^ ' ' - . ■ ' 
■ */ 

. • : void (SAL^CALLr* ippegist er Inter face )i;C * pEnv, , . 

void ** pplnterface, 

40 , - ^ . ^ . . ' .rtl_String ** ppOId.. . ^ 

• s . ^ypQiijj^interfaceTypeDescriptibn - ' ■ " « 

pTypeDescr. 

uno_regAcquireFunc acquire ) ; 

45*- "... v ** You. have' to revoke ANY J-ihterf ace . that: has been registered via this 

method . 

" * ©param pEnv tKis environment 

* ©param pOId object id of interface to be revoked 

50 * ©param pTypeDescr type description of interface to be revoked 

*/ 

void (SAli_CALL * revoke Inter face) < uno_Environment * pEnv, 

rtl_String * pOId, 

typelib^InterfaceTypeDe script ion * pTypeDescr. ) ; 

/** . ■ . 

* Retrieves an interface identified by its object id and type from 

* this environment. 

*<BR> : r . 

60 * ©param pEnv this environment 

* ©param pplnterface inout parameter for the registered interface; 

* (0) if none was found 

©param; pOIdr object, id of- interface to be retrieved. . ^ ^ 

* ©param pTypeDescr type description of interface to be retrieved 
65 */ 

void (SAL_CAIiL * getRegisteredlnterf ace) ( uno__Environment * pEnv. 

void ** pplnterface, , t-^ 
rtl_String * pOId. 

typelib_Interf aceTypeDescription * 
70 pTypeDescr ) ; • - " 



Annex 



r.27- 



* Retrieves the object identifier for a registered interface from 
; * this environment. -jr. • \. - 

5 ' *<BR> 

* ©param pEnv this environment, ■ . ^ _ 

' * ©param ppOId *inout parameter for • bbject 'id of interface; (0) if none 

was found ... - . \ 

' ^. r • * ©param pinterface a registered interface - - - 

10 * ©param pTypeDescr type description of interface 

void (SAL_CALL * getRegisteredObjectldentif ier) ( uno_Environment * pEnv, 

rtl_String,,** ppOId, 
void * pinterface, 

15 typelib_InterfaceTypeDescription * 

pTypeDescr ) ; 

- /** • ' 

* Disposing callback function pointer that can be set to get signalled 

20 be fore . , : ' ' . . k 

* the environment is destroyed. 

*<BR> - . ^r,- - . ' - • . ■ - , ; ' ' 

* ©param pEnv enviroixment that "is beiiig disposed 

*/ . - . 

25 void (SAL_CALL * environmentDisposing) ( uno_Envir6nment * pEnv ) 

/** 

* Computes an object identifier for the given interface; is called by 

* the . environment implementation. J . - ^ . .y , ^ . 
30 * <BR> " - ^ • 

, r * ©param pEny corresponding, environment . „ . ^ .. . . >. , , . 

* ©param ppoid out param:"' computed*" id ^' " ; S " 

* ©param pinterface an interface 

'./.*/" . - . !^ ^:t£' 'Vi i; c^c c^t^.z- \. ,o " 'i -.ro ^.u" 

35 void (SAL_CALL * computeObjectldentif ier) ( uno_Environment * pEnv, 

• f > v-j,. r.tl^String- ** ,ppOId, ,vo\d-;*. pinterface )^^^^ 
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* Flinctibh to acquire an^ iriteirf ace . 

40 ^ , _ *<BR> . . _ . . . . . .......... ■ . . V - 

* ©param -pEnv corresponding , environment • ' ^ - -^^ ^. . ^ ; j .. , 

* ©param pinterface an interface 

void {SAIi_CAIjL * acquirelnterface) ( uno_Environment * pEnv, void * plnter- 
45 face );..;.'• '\ .' ,: :\ ^ . \ / 1 , T";. / j ' ^ ~: I '^^ \' ^ 

* Function to release an interface. _ ... 
• ■ *<BR> ' ' ""' ' *' ' ■ ^ • 

* ©param pEnv corresponding envirorunent ^ . 
50 " ■ * ©param pinterface^ an interface' • * 



face ) 
}; 



*/ 

void {SAL_CAIiIii, * -releaselnterface) ( r vuao_Environment- * pEnv, . void * .plnter- 



Environments, as defined above, consist of several fields. The first fields are used 
for identifying the environment, for specifying the hardware, the process, pd 
maybe a session specific ID. There is also a context pointer which can be used for 
specific classes of environments, e.g. when it is known that there is a Java envi- 
60 ronment the yirtual machine pointer can be stored there. 
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In order to use environments, these environments regularly have to be registered. 
An existing environment may be obtained by calling imo ^getEnvironmentQ. A 
.new environment can be created, by either implementing it directly or by using a 
simple default implementation, \yhich is frequently also sufficient, by calling, in 
5 the given example, uno_createDefaultEnvironmentO with the environment's name 
and its acquire and release function for interfaces. 

In order to improve the performance the bridges should use the shortest way be- 
tween two environments. Especially, if there are programs instantiated in the 
10 identical environment, the 5;ommunication between them should be direct and not 
over a proxy and a stub. . , : = ^ 

Mapping is the direct way to pubhsh ah interface in another environment. That : 
means an interface is mapped froM^a/jSi^TL^^^^ a target environment 

15 so that methods may be invoked on a mappe<i interface in the targiet environment 
which are delejgated to -the originating interface in the source enviromnent. A 
mapped interface may also be called a pcpxy or a stub. Mapping an interface from 
an environment A to an environmenfeB re^quires that several steps are performed: 
First, the origin of the interface from eiivironment A has to be retrieved (call 

20 getlnterfaceOriginQ on enviroiunent A). For this purpose, the envirormient A 
looks into its proxy interfaces table to ch'ebk if there is such an interface already 
known (pointer and type). If the answer Jisi-ncl, then this interface must originally 
- come from' envirormient A, or else it must originate from any other environment 
and its origin must be known, since each proxy interface must have been regis- 

25 tered with its origin. Second, an existing proxy interface has to be looked for in 
environment B wiHi the saine origin and type (call getliiterfaceO on environment 
B). If a proxy interface of that origin and type is already in use in environment B, 
then this interface is acquired, or else a new proxy has to be constructed wrapping 
the source interface from enviroiiment A. The fresh proxy interface is then to be 

30 registered via registerlnterface() on its first acquire() and revoked via revokelnter- 
face() on its last release() from its environment. This second step has to be syn- 
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: chronized .with other threads in order-fq get access to mapping tables of an envi- 
ronment by getting an access interface (lockAccessQ) from the environment. Then 
an unlockAccessQ function has to be called. 

5 Function of Stub and proxy: < 

The stub is .encapsulated in an. object which delivers and transforms the binary 
specification adapted calls to the stub. This object is the proxy of a stub in the first 
binary specification. This proxy which calls and attributes access will be similar 
10 with the binary specification firpm which the. call was made. The calling to the 
'Stub is shown in Fig. 8. . r ' . r ^ ■ 

First in step 81 a type.saye call (e.g. acquire, querylnterface, ...) is made at the 
' proxy.3. This type save call will be transformed by the proxy 34o a corresponding 
15 call in step 82 and dispatched to the stub ;4 in. step 83. After that, the return value 
of this call is transformed in step 84 to the type expected by the binary specifica- 

t,^.i;tion.c: : ■ -lO .-^i.. .z^-'^. ^r.j^r.:.,. . j.ic-'i ^ v ■ ' ' > 

ii, >The proxy Js binary specification^ specific.^ So fit is- possible ^to. put this.qbject 
20 seamless into, the bin,ary specification.^ ^^^^^^ ^ . . ./i . - \„ : 

A stub object is also created which implements aniiinp^interfa^e .and transforms 
and delegates thCr calls to the second program^ implemented in a specific pro- 
gramming language (e.g. C-H-, Java,...). Fig. 9 describes a call through a ^stub 4 to 
25 the second program 2. 

- In a first step,91 the dispatch fiinction is called. If proxy and stub are runiung in 
the same process, the dispatch funotion of . the stub is directly called -by the proxy. 
:In a distributed environment this is. not possible. In this case the abstract virtual 
30 channel has to provide this fimctionality. On the proxy side th^ proxy will accept . 
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the request and transmit it to the stub side; On the stub side the stub has to call the 
dispatch function. ' - - - - 

The stub 4 detects the interface and the method which should be called at the sec- 
5 ond program 2. Then in step 92 the call was transformed into a specific binary 
specification by the stub 4 and the second program 2 was called in step 93. After 
that, the retum value was re-transformed^o the other binary specification in step 
■94. ' ' ■ ' *- ■ - 

10 Ttie stub makes all transformations to the binary specification in which the second 
program is implemented. This is in this example the second binary specification. 
This makes it possible to implement the second program in the second binary 
specification. For example:' In C-H- . excq)tions, multiple inheritance and deriva- 
- tion can be used. In' addition^to-the binary speciSS there are the type descrip- 

15 ' tions; which must bfe mapped in ttie birfaz^ specifieatioii of the second program. 

In order to enable to call firom one binary specification or object model to another 
the stub and the proxy have to undergo a binding process. The proxy allows to call 
' ' from one binary specification to the uii6£interface/ while the stub allows to call 
20 through the uno_interface to the second pro^ani. The binding of the stub and the 
proxy is initiated by the first software program 1 and is shown in Fig. 10. In a first 
' ^ step 101 the^generation of a stub with the binary UNO specification in the stub 
' factory 102 is shown. In a second .step 103 a proxy is created based on the gener- 
ated stub^in'^thc proxy factory' 104.:— 
25 . . . ^ . 

Each call to the proxy is delivered to the stub. The stub prepares the call and calls 
the second program in the corresponding binary specification. Figi T l shows ex- 
emplary the call from a first softwaie prograni 1 in a programming- language like 
"objective c" to a second software prbgrahi 2 which may be iniplemented in the 
30 • programming language C+-f. - ■ : . : ^ . . / 
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The first software program 1 uses the programming language "objective c". The 
. proxy 3 makes the interface available to the first software program 1 in the first 
binary specification. This means the first software program 1 uses the first binary 
. specification to manipulate the second software program 2. For example, this may 
5 be effected by the call „char =^ pOldText = [ myObject changeText: "test"]" in step 
11 1, The proxy .3 transforms the parameter of type string to the binary specifica- 
tion in step 112. Then, the proxy 3 dispatches in step 1 13 the call to the stub 4, 
The necessary information, including a^ metiiod type description,, parameters, an 
address for the return value and an^^address for the exception, if any occurs, is de- 

10 livered to Xhe stub 4, The stub 4 transforms in step 1 14 the string from the binary 
UNO specification to a second binary specification string. The stub 4 calls the 
right method at; the second software rprogram 2 in step 115, in our example 
"pComponent->changeText("test^^'\ The ^sU^^ 4 must catch all jkind of exceptions 
thrown by the second -software progr^. 2. If the method returns normally, the 

15 string is transformed in the step 1 16 to the binary UNO specification and stored at 
the place given through the dispatch call. If an exception is thrown, the exception 
V, is transformed and stored at the.addres? given t^ call. After the 

dispatch call returns the proxy 3 transforms Jn step 1,17 the string to a first binary 
specification string and- returns from^ they/changeText" call. If the call terminates 

20 .by^an exception, the exception is returned to the first software -prograrn 1. It is up 
to the first binary specification in which manner the exception occurs (the Tobjec- 
tive c" language does not support exception handling). 

Fig. 12 shows the advantage of the binary .UNO specification as an intermediate 
25 binary specification as^it was described above. In a first step 121 the first software . 
program 1, for example written, in the. programming language G-H-, transmits one 
„ command in a-first binary specification, in this example the command "setText("a 
: test")*', to the proxy 3. Regularly, the, -first software progrsmi will transmit, more 
than .one command, for example, also the acquire, the release and. the querylnter- 
30. face command as described abpye. This command will be transformed by the 
^ proxy 3. in the next step 122 from the first binary specification into the binary 
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UNO specification. The command in the binary UNO specification contains the 
following inforaiation: the parameter "a test", the return address, an address for 
the exceptions, and the type description of the command "setTexf*. The type de- 
scription of this command will include, in this example, the name of the command 

5 (setText), the t>pe of the parameter and the retum type. This transformed com- 
mand will be transmitted to the-stub 4 in the step 123. Then, the stub 4 transforms 
in step 124 the command from the binary UNO specification into the second bi- 
nary specification, employed by the second software program 2 which was writ- 
ten, for example, in the programming l^anguage Java. The stub 4 employs for this 

10 transforming step only one dispatch ■mechanism. This is a mechanism^ which will 
be employed for each eomm^d transmitted by the proxy 3, since it is able to dis- 
patch the name of the cbmmand aiid the other relevant information to the second - 
software program -2. In the final step 125 the second software program 2 executes 
the command "setText'\^ The response to -^^^^ command will be transmitted and 

15 transformed in a'ciorrespbrtding w^ ; . . ' 

Fig. 13 show^s a scenario' wHere^ btetw 3 and the stub 4 an interceptor 

130 \s inserted. This means, that the^sfub 4 and the interceptor 130 are created in a 
first step; while in a second step the stub '3 is created based on information about 
20 the stub 4 and the interceptor 130. Therefore, the proxy 3* wilL communicate only 
with the interceptor 130 arid not with the 



Such an interceptor may be able to carry out, for example, an accounting fimction 
- or a security check fimction: If; for example, the first software program 1 wants to 

25 " use a fimctionality of the second software program 2, the interceptor may be able 
to discover if the user of the first software program is authorized to use this func- 
tion and to debit the accourit of the user -'if the user has to pay for tiiis fimctional- 
ity. Such an interceptor may also be used, for example, to help debugging the 
communication between a first software prograni 1 and a second software pro- 

30 " gram 2. Li such a case the interceptor may provide an' alarrh fiahctiofi which will 
be initiated, if a predefined fimctionality is called. If the ftinctions requested from 
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the second software program .2 may be grouped as one transaction, it may also be 
possible that an interceptor cancels all abready executed functions of this group, if 
one function fails. Such an interceptor has the advantage that only one interceptor 
may be employed: for every .function or method-of an interface and for all binary 
5 tspecifications of software programs which conmiunicate via the intermediate bi- 
nary specification used by ..the stub 4 and the proxy 3. ^ ^ 

Fig. 14 shows a flow chart representing the use of an^nterceptor as checking and 
accounting function for a fax service. In this example, a user of a first software 
10 . program .using a first binary specification wants 4o use. the fax, service of a second 
software program using a second binary language. This fax~service may distin- 
guish between two kinds of users. A standard user may have to pay for each fax 
and a premiiam user may have to pay a monthly standard fee. 



15 In order to enable the communication between the two software programs a stub 
and a proxy will be created and combined and arranged together with a specific 
interceptor in a way shown in Fig. 13. Then, the following steps may be carried 
out in using the invention. 

20 In step 140 the first software program sends a command including the desired fax 
number, the corresponding fax file and the identity of the user to the proxy. The 
proxy transforms this command into the intermediate binary specification and 
forwards it to the interceptor in step 141. The interceptor checks in step 142 
whether the user is a standard user. 

25 

If the answer is "Yes", that means the user is a standard user, the interceptor may 
deteremine in step 143 whether the user has enough credit. If the answer to this 
question is 'TMo", the user will be informed about his insufficient credit status and 
about the fact that the fax was yet not sent in step 144. If the answer is "Yes", that 
30 means that the user has enough credit, the interceptor will initiate, in this example. 
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the debiting of the user's account in step 145 and forward the received command 
to the stub in step 146. 

If the answer in step 142 is '*No", that means the user is a premium user, the inter- 
5 ceptor will forward the command received from the proxy directly to the stub in 
step 146. The stub will transform this comniand from the intermediate binary 
specification into the second binary specification and forward this command to 
th6 second software programHn step 147. Then the fax may be sent. 

10 It will be understood that the present invention is not limited to the examples gi- 
ven and explained in detail. " i . 
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A method for presenting a runtime environment component service by a 
first computer system (1) to a second computer system (2) over a commu- 
nication network (3), said method being performed by said first computer 
system (1), and comprising the steps of: 

a) receiving a request for a runtime environment component service 
via said communication network (3), said request being generated 
in said second computer system (2) by a lightweight component 
(210) corresponding to said runtime environment component serv- 
ice, 

b) accessing a runtime environment component (101, 102, 103, 104, 
105, 106, 110) being able to provide said requested runtime envi- 
ronment component service, 

c) executing said runtime environment component (101, 102, 103, 
104, 105, 106, 110) on said first computer system (1) for producing 
a result according to said received request for a runtime environ- 
ment component service, 

d) transmitting, over said network (3), a response comprising said re- 
sult to said second computer system (2). 



30 



A method for providing a runtime environment component service firom a 
first computer system (1) over a communication network (3) to a second 
computer system (2), said method being executed on said second computer 
system (2), and comprising the steps of: 
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a) generating a request for a runtime environment component service 
by means of a lightweight component (210) of said second com- 

'i puter system (2), \yherein said lightweight component (210) corre- 
sponds to said runtime environment component service, 

b) transmitting said request for said runtime environment component 
service to said first computer system (1) over said communication 
network (3), and : - v : : 

c) y receiving a. response i comprising. a: result according to said re- 

quested runtime environment component service, said result being 
• produced by a :-runtime . environment component (10.1, 102, 103, 
104, 105, 106, 110) executed on said first computer system (1) and 
transmitted with saidi response by said first computer system (1) 
over said network (3). -c^:. . ^ , , ^ . . . ... 

A method according to any :of^th'e:prec,eding claims, wherein said light- 
v/eight component (2 1,0) has a^small^size Is compared to the, total size cs in 
bytes of the at , least one runtime: enviromnenf components. (^^ 102, 103, 

104, 105, 106, 110) providing^a^spr/ice corresponding to said lightweight 
component (210) including any auxiliary software programs needed to 
execute said runtime . environment coniponents (tOl, 102, 103, 104, 105, 
106,110). . : 7.: -s. , : . > . . 

A method according to claim 3, wherein said size Is is equal or less than 
ten percent of the total size cs. 

A method according to any. off the preceding claims, wherein said light- 
weight component (210) may be downloaded from said .first, computer 
system (1) to said second computer system (2) over said network (3) in a 
time.t equal or less than (8 N / Cg) ti, wherein N is the total- size in bytes 
of the at least one runtiirie.emdronment component (101, 102,. 103, 104, 

105, 106, 110) providing a service corresponding to said. lightweight com- 
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ponent (210); Cb is the average .bandwidth of the network (3), and ti is the 
total time needed to initialize said runtime environment components (101, 
102, 103, 104, 105, 106, 110) providing a service corresponding to said 
lightweight component, (2 10) in the local environment on said first com- 
puter system (1) in which it is embedded. 

A method according to any of the preceding claims, wherein said Ught- 
' weight component (210) is a non-visual li^tweight component. 

A method according to any of the preceding claims, wherein said light- 
weight component. (210) may^:be downloaded from said first computer 
^ system (1) to said second computer system (2) over said network (3) in a 
time t equal or less than ten seconds. / 

A method accordingito anycof ihecpr^^^ claims, wherein said light- 
. weight component (2 10) is. transmitted from said first computer system (1 ) 
over said network (3> to said second computer system (2):prior to per- - 
forming a method of any of. the^^^ 



• A method according .to any of the preceding claims, wherein said runtime 
environment component services comprise at least one of the following 
functions: graphic functions, word processing functions, docxmient editing 
. - functions, printing fimctions.. ^^ ^ : ; . . . - ^ 

A method according to any of the preceding claims, wherein said first 
' computer system (1) is a seryer system, and said second computer system 
■ ' (2) is a client system. . - . . - 

- . A method according to. any of the preceding claims, wherein said runtime 
: environment components (101,. 102, 103; 104, 105, J06, 1 10). comprise at 
least one application programming interface (API) 
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,12. A method according to any of the preceding claims, wherein said runtime 
environment component services comprise output services:on said second 
computer system (2). 

5 . • . . ^ ■■ -^ - - . ■-; 

13. A method according to any of the precedings claims, whefein.said request 
for a runtime environment component service is transmitted by said second 
computer system (2) into said network (3) by a communication component 
(200) of said second .computer, system (2), andv wherein said response :pf 
10 , . . : said first computer system (1) to said, request is transmitted into said net- 
. . , . work (3) by a conmiunication component (10Q);pf said first computer sys- 
tem (1). 

. 14. A method according-to the preceding-claim, wherein. said commvuiication 
15 I component (200) is ablcrto* gerijerate acstub object,(200') and wherein said 

commimication component (IQQ) Is able^o generate a proxy object (100'). 

15.. . A method according to, any of ithe. preceding, claims,, wher^ein said trans- 
/ . . mitted request complies with a-predetermined communication prptocoL 
20 . ■ i. .::\ \ ' ■ >■ , ■ .^^ 

16. A method according to any. of the preceding claims, wherein said trans- 
mitted request comprises identification data of said first computer system 
(1), identification ..data of said second computer' system (2), identification 
data of said runtime environment component seiyice, and input data to said 

25 : nmtime. environment component service. ,^ . , ^ x::-^ 

' : , ^ •'■) ,^ . t 

17. A method according to any of the preceding claims, wherein said trans- 
mitted result comprises identification, data of, said. first computer system 
(1),. identification data of said' second computer system (2), identification 

30 . data; pf, said runtime environment, component, service,, and output data of 

said runtime environment component service. 
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18. • A method according to one of the preceding claims, wherein said commu- 
nication network (3) complies with the Internet protocol http. 

5 19. A method according to any of the preceding claims, wherein said request 
and' said response are transmitted over a secure channel of said communi- 
^ ^ cation network (3). - - ' 

20. A method according to any of the-preceding claims, wherein said first 
10 computer system<(l) has access to runtime environment components (101, 

102, 103, 104, 105, 106, 1 10) which reside on a further computer system. 

21, A method according to any of the preceding claims, wherein said request 
^ for said nmtSme environriaent is generated in said sec-^ 

15 ' -ond computer systeni (2) by tisiiig a Remote Visualization Process (RVP) 
(220) and a Abistract WindoW TooMt (260).: 



'A rnethod according" to any of thecprecedihg claims, wherein said request 
for said inmtiiile environm service is received in said first 

computer system (1) by using a Remote Visualization Process (RVP) (120) 
and a Visual Class Library (VCn) (140). - 

23. - A method according to any of the pireceding claims, wherein said response 
^ ^ ~ of said first computer system (l)-is transmitted to said second computer 
25 system (2) by using a Remote Visualization Process (RVP) (120) and a 

Visual Class Library (VCL) (140). 

- 24. ^ A method according to any of the preceding claims, wherein said response 
of said first computer system (-1) is received in said second computer sys- 
30 ^ tem (2) by using a Remote Visualization Process (RVP) (220) -and a Ab- 

stract Window Toolkit (260). ^ - 



22: 
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25. A method for presenting runtime environment component services by a 
first computer system (1) performing the method according to claim 1, to a 
second computer system (2) performing the method according to claim 2. 

26. Data carrier means containing computer software for performing the 
method according to any of the preceding method claims. 

27. A computer system for performing the method according to any of the 
10 preceding method claims. 

28. A set of runtime environment components (101, 102, 103, 104, 105, 106, 
110) for use with a method according to any of the preceding method 
claims. 



29. A data base comprising a set of ^nintime' environment components (101, 
102, 103, 104, 105, 106, 110) relating to said runtime environment com- 
ponent services according to anyfof the preceding method claims. 
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A method for presenting a runtime environment component service by a first 
5 computer system (1) to a second computer system (2) over a communication net- 
work (3), said method being performed by said first computer "systerri (1), and 
comprising the steps of: 

a) receiving a request for a runtime environment component- service via said 
communication network (3), said request being generated in said second com- 

10 puter system (2) by. a lightweight component (210) corresponding to said run- 

time environment component service, 

b) accessing a runtime environment component (101, 102, 103, 104, 105, 106, 
110) being able to provide said requested runtime environment component 
service, ^^^^ ; ' ; <^ 

15 c) executing said runtime environijient component (101, 102, 103, 104, 105, 106, 
110) on. said first computer system. CD" for producing a resuh according to said 
received request for a runtime environment component service, 
d) transmitting, over said network (3), a response comprising said result to said 
second computer system (2). 
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